TDD requires you to think about things a little differently. First, you determine what you intend to test, and how you intend to test it before writing code for the solution.
For a GUI, this can become quite complex, and frankly, your GUI should never contain any logic that can be in a separate layer. For example, the displayed value should come from an object that has nothing to do with the graphical interface, but can be checked individually. This allows you to develop the basic business logic (model and controller) separately from the display (view). This is an MVC pattern. Test Driven Development simply means that you verify that you can before writing more code, and by adding more code, more tests will start.
I would rather focus on my design and make sure everything that generates a text value works as expected. The GUI should be βdumbβ and focus only on displaying or retrieving values, with little if there is a problem if the displayed values ββare really correct.
As a graphical interface, it is usually difficult to test using automated tools (correctly tested), I would avoid this as much as possible and separate my GUI from my actual application as much as possible. You can then test the GUI once to make sure that it displays what it should have and focus on business logic without having to run ongoing tests in the GUI, since you are not touching this code.
Ewald
source share