How is TDD JFrame?

I am working on a new project where I want to display some data on the screen. I started using TDD, which is new to me, but I like the idea and get along well so far.

I installed JFrame, add Textarea and put the text there, but how can I check this correctly? Or is it wrong thinking in the context of TDD on my side? I want to be sure (in TDD mode) that the data will be displayed correctly! the creation of the displayed text is correctly covered by tests, but the display is not.

Here is a simplified example:

public class MyTextDisplay { public static void main(String[] args) { JFrame my_frame = new JFrame("DisplaySomeText"); my_frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JTextArea textArea = new JTextArea(5, 20); textArea.setEditable(false); my_frame.add(textArea); my_frame.setVisible(true); //this would be in a separate method textArea.append("Hello World"); } } 
+7
source share
1 answer

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.

+5
source

All Articles