Geek Answers Handbook

TDD with charts

I have an application that draws a chart. A chart follows a certain pattern,

for example, the form X is included in the form Y, the forms {X, Y} belong to the group P ...

A diagram can become large and complex (think about a circuit diagram).

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

+4
source share
4 answers
  • Find out where the complexity of your code is.
  • separate it from an untested visual presentation
  • check him

If you have no visual complexity, you are not writing a program, you are creating a work of art.

Unless you use the horribly buggy compiler or something like that, I would avoid any tests that boil down to "the source code of the test does what it says." Any test functionally equivalent:

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

can be deleted without loss.

+1
source

It is difficult to write certain unit tests for something visual like this unless you really understand the exact sequence of API calls that will be created.

To check for something “visual” like this, you have three parts.

  • "Spike" to get the right look, scale, color and all that. In some cases, this is almost the entire application.

  • In a “manual” test, this creates some final images to make sure they look right for someone. There is no easy way to verify this, except to actually view the actual output. It is hard to automate.

  • Discard the graphic components to make sure your application names the graphic components correctly.

When you make changes, you need to run both tests: does the API call correctly? and does this sequence of API calls call an image that looks right?

You can - if you really want to break a brain cell - try creating a PNG file from your graphics and test to see if the PNG file looks right. It is hardly worth the effort.

As you move forward, your requirements may change. In this case, you may have to rewrite the spike first and make things look right. You can then infer the sequence of API calls to create automatic unit tests from the surge.

It can be argued that creating a burst violates TDD. However, the spike is designed to create a test graphics module. You cannot easily write test cases, because the test procedure "will show it to a person." It cannot be automated.

+1
source

You can first transfer the original input to some intermediate format that you can check. Then you forward this intermediate format to the actual drawing function, which you must check manually.

For example, if you have a program that enters percentages and displays a pie chart, then you may have an intermediate format that accurately describes the size and position of each sector.

+1
source

You have described a data model. The application, apparently, is doing something, and not just sitting there with some data in memory. Recording tests that implement the behavior of the application and checking the result is what is expected.

0
source

More articles:


All Articles