Learn what tools for use to test your code's functionality for Beginner

There are some general rules of testing:

1. A testing component must focus on a single small bit of functionality and show it correct.
2. Every test component has to be fully free. Each of them has to be capable to run only and also in the test collection. The suggestion of this rule is to each test having to be burdened with a new data set and may have to do some cleaning afterwards. This is usually handled by setup () and tear down () methods.
3. Try hard to create tests that run fast. If one single test needs more than a little milliseconds to run progress will be slowed down. In some cases tests cannot be quick because they need a complex data structure to work on and this data structure must be loaded every time the test runs.
4. Study your tools and learn how to run a single test. Then when raising a function inside a module run this functions tests very frequently perfectly mechanically when you save the code.
5.  At all times run the full test collection before a coding session and run it again after. This will provide you further confidence that you did not break something in the rest of the code.
6. It is a good design to implement a hook and eye that runs all tests before pushing code to a shared storage area. If you are in the central point of a development session and have to cut short your work it is a good idea to write a broken component test about what you want to develop next. When coming back to work you will have a pointer to where you were and get back on track faster.
7. The first step when you are debugging your code is to write a new test pinpointing the bug. While it is not always possible to do, those bug catching tests are among the most valuable pieces of code in your project.
8. The method guide here is to some extent different than that of running code where short names are often preferred. The cause is testing functions are never called explicitly. Square () or even square () is used in running code but in testing code you would have names such as test_square_of_number_2 () and test_square_negative_number (). These function names are displayed when a test fails.
9. While something goes wrong or has to be changed and if your code has a good set of tests you will rely largely on the testing collection to fix the problem. Hence the testing code will be read as much as or even more than the running code. A component test whose purpose is unclear is not very helpful in this case.
10. One more use of the testing code is as an introduction to fresh developers. When somebody will have to work on the code base, running and reading the related testing code is often the best they can do. They will discover the hot spots where most difficulties arise and the area cases. If they have to add some more functionality the first step must be to add a test, by this means and make sure the new functionality is not already a running path that has not been plugged into the interface.

Share on Google Plus