开发者

Which kind of test for which part of the software?

开发者 https://www.devze.com 2023-03-16 21:49 出处:网络
I am new to TDD and want to know which kind oft test i need for which part of the software. Currently my tea开发者_JS百科m creates a relative complex editor on the Netbeans Platform, where i have to

I am new to TDD and want to know which kind oft test i need for which part of the software.

Currently my tea开发者_JS百科m creates a relative complex editor on the Netbeans Platform, where i have to integrate an external editor and also write own stuff. So how can i do the tests best for the GUI, the own code, integration code? Where do i create coded tests and where should i use test cases and testers?

We are considering to use scala specs or junit for the coded tests.

Thank you for your help!


As a general rule you should consider writing a test case for every function/method you write in your class.

In our TDD process we simply follow the rule that every Java class must have a corresponding JUnit class that contains @Test method for every method of that Java class. Then we follow this with 'code coverage' that will tell us how much of the code we have actually written has been tested. For this I suggest looking at a tool called Cobertura (link here) which provide us an easy visual way to examine the percentage of our code that has been tested. it works by simply detecting how many line of code your JUnit class has tested for every Java class. This will provide you with a good idea about what functionality in your code has or has not been tested. We usually aim to have about 80% of the code tested (easier said than done though)

consider writing test cases for your high priority functionality first to get you started.

We don't usually write JUnit for the GUI. not sure if there is a way but we leave the GUI to be tested by the testers when the application is going through the usual Testing phase.

hope this helps a little.


This is very subjective, but I would suggest cleanly separating your gui and writing solid unit tests against the interface between the gui and the business layer. Don't worry about automating the gui testing. This will naturally force you to create a clean separation of concerns between the layers.


GUI is for human interaction, therefore automated GUI test will result in epic failures. If you want to test GUI properly, you'll just need humans.

However, you can test how your app will react to different user actions. Especially, think to test how your app should cope with user errors (for instance, when letters are written in a numeric only input field).

If the distinction between unit tests, functional tests and integration tests is not clear for you, don't bother too much. Try to test as much thing as you think necessary (again don't forget worst case scenarios). When in doubt, remember that it's better to test too much, than to little.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号