TDD with diagrams

Question

I have an app which draws a diagram. The diagram follows a certain schema,

for e.g shape X goes within shape Y, shapes {X, Y} belong to a group P ...

The diagram can get large and complicated (think of a circuit diagram).

What is a good approach for writing unit tests for this app?

Answer 1

You've described a data model. The application presumably does something, rather than just sitting there with some data in memory. Write tests which exercise the behaviour of the application and verify the outcome is what is expected.

Answer 2

It's hard to write defined unit tests for something visual like this unless you really understand the exact sequence of API calls that are going to be built.

To test something "visual" like this, you have three parts.

1. A "spike" to get the proper look, scaling, colors and all that. In some cases, this is almost the entire application.

2. A "manual" test of that creates some final images to be sure they look correct to someone's eye. There's no easy way to test this except by actually looking at the actual output. This is hard to automate.

3. Mock the graphics components to be sure your application calls the graphics components properly.

When you make changes, you have to run both tests: Are the API calls all correct? and Does that sequence of API calls produce the image that looks right?

You can -- if you want to really burst a brain cell -- try to create a PNG file from your graphics and test to see if the PNG file "looks" right. It's hardly worth the effort.

As you go forward, your requirements may change. In this case, you may have to rewrite the spike first and get things to look right. Then, you can pull out the sequence of API calls to create automated unit tests from the spike.

One can argue that creating the spike violates TDD. However, the spike is designed to create a testable graphics module. You can't easily write the test cases first because the test procedure is "show it to a person". It can't be automated.

Answer 3

You might consider first converting the initial input data into some intermediate format, that you can test. Then you forward that intermediate format to the actual drawing function, which you have to test manually.

For example when you have a program that inputs percentages and outputs a pie chart, then you might have an intermediate format that exactly describes the dimensions and position of each sector.

Answer 4

1. Find out where the complexity in your code is.
2. separate it out from the untestable visual presentation
3. test it

If you don't have any non-visual complexity, you are not writing a program, you are producing a work of art.

Unless you are using a horribly buggy compiler or something, I'd avoid any tests that boil down to 'test source code does what it says it does'. Any test that's functionally equivalent to:

assertEquals (hash(stripComments(loadSourceCode())), 0x87364fg3234);

can be deleted without loss.