I have googled and read few articles about the TDD for UI. I am not very much clear about how to start the implementation of the Graphics Application using Test Driven Development or how to write unit test cases for graphics application.

The main features of the application is rendering the UI based on the user inputs.

  • draw canvas
  • Rendering of the lines , circles, oval, square and other shapes.

I am finding it difficult how to test the rendering of the shapes -

  • Whether to test that given draw methods are invoked or not.
  • Check if end points for given shapes are calculated correctly or not

2 Answers 2


When people use the term "Test Driven Development" it's often assumed they're talking about unit testing code. But there are other types of tests you can use to drive your development.

If you do want to do image comparisons for tests, that certainly possible to do. There are measures like deltaE color difference which can be used to tell if an image your code generates has changed from one run to the next.

You wouldn't want to run these as unit tests which are traditionally run before every build, for example. But you might run them after every commit to your source repository, or once per night as part of your continuous integration system.

Where I work, we've successfully used such tests to keep us informed of rendering regressions, errors in rendering, or other visual changes and differences that we might want to know about. It's not as simple as writing a unit test to see if your code handles a particular edge case, but it can be very useful in understanding how code changes affect rendering.

  • This is great, and should be the accepted answer coming from someone with a background in testing renderings.
    – Engineer
    Jan 7, 2020 at 8:22

It depends on what your code is doing, i.e. what is the actual logic you need to test.

I presume that your application uses an API in order to draw objects such as circles, lines, etc. In this case, your goal is not to test whether the image/screen corresponds to what was expected—if you requested the API to draw a circle at a given position, it belongs to that API to reflect the image/screen accordingly. Instead, what you need to test is that when a caller invoked a specific method of your code, then your code called a method to draw this or that.

You do this by using fakes or mocks. In other words, when testing a specific class, you won't inject the real API which draws objects on an image/screen, but instead a substitute that you've written specifically for the tests, and which will do no real drawing. Instead, the substitute will just, for instance, record that you called a given method with specific parameters. Later on, your test will request this substitute to tell if the method was called, and succeed or fail depending on that.

  • thank you i have similar scenario and was finding difficult to write test cases for it. Aug 5, 2018 at 8:34
  • I like this perspective. What you test is your code and your expectations. What I'd add is this is also where you test the design of your own abstractions, interfaces, names, and API because tests let you see them being used. Make sure they make sense even when you don't look inside. Aug 5, 2018 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.