AlecMcE.com

With simple colors you’re still in the realm of unit testing possibility since you could conceivably calculate the correct result by checking individual pixels drawn. If you add images though, it’ll probably be too complicated. That also tends to be a problem for unit testing: asynchronous loading that takes an indeterminate time, comes in an indeterminate order, depends on all the other loads and the results of their loading callbacks, etc. Still, I can’t wait to see where this goes. Do you think you’ll post source code for this some day?

With simple colors you’re still in the realm of unit testing possibility since you could conceivably calculate the correct result by checking individual pixels drawn. If you add images though, it’ll probably be too complicated. That also tends to be a problem for unit testing: asynchronous loading that takes an indeterminate time, comes in an indeterminate order, depends on all the other loads and the results of their loading callbacks, etc. Still, I can’t wait to see where this goes. Do you think you’ll post source code for this some day?

Thanks Jackson.

The point of the excercise was to check firstly that the cuboids rendered, and that infinitely many rendered correctly.

I can (and do) test that the renderer works as I want it to by doing the maths myself for a few pre-calculated cuboids to see what the inputs to the moveTo and lineTo commands will be. This serves as an additional test in two ways: to validate that there’s nothing special about the cuboids I tested manually, and to validate that I’m sending sensible inputs to the graphics methods.

Interestingly I did write this in the spirit of test-driven development: I created the application as a test-harness, then wrote the unit-tests, then the production code. Once the unit-tests ran green, I tested in this graphical harness. It is a belt-and-braces approach which seems to work pretty well for this sort of work.

Oh, and sadly I’m not really at liberty to publish the source code, I’m afraid. It’s not a big thing, but it’s part of something much bigger which is not mine to give away.

Thanks Jackson.

The point of the excercise was to check firstly that the cuboids rendered, and that infinitely many rendered correctly.

I can (and do) test that the renderer works as I want it to by doing the maths myself for a few pre-calculated cuboids to see what the inputs to the moveTo and lineTo commands will be. This serves as an additional test in two ways: to validate that there’s nothing special about the cuboids I tested manually, and to validate that I’m sending sensible inputs to the graphics methods.

Interestingly I did write this in the spirit of test-driven development: I created the application as a test-harness, then wrote the unit-tests, then the production code. Once the unit-tests ran green, I tested in this graphical harness. It is a belt-and-braces approach which seems to work pretty well for this sort of work.

Oh, and sadly I’m not really at liberty to publish the source code, I’m afraid. It’s not a big thing, but it’s part of something much bigger which is not mine to give away.