Testing Tutorial: What is Testing

From KratosWiki
(Difference between revisions)
Jump to: navigation, search
(Good Practice in Testing)
Line 9: Line 9:
 
* '''Test one thing''' if a test does different things (like "TestModelPart") a failure gives less information and a debugging would be needed to see where is the failure and why. But if it only tests one thing then the failure says that in the first glance. (like "TestInitializingModelPart Failed")
 
* '''Test one thing''' if a test does different things (like "TestModelPart") a failure gives less information and a debugging would be needed to see where is the failure and why. But if it only tests one thing then the failure says that in the first glance. (like "TestInitializingModelPart Failed")
  
* '''Faster is better''' running a slow test would be tedious for the developers and they would avoid long tests. So an effort should be made to find a fast test.
+
* '''Faster is better''' running a slow test would be tedious for the developers and they would avoid long tests. So an effort should be made to find an implement a fast test.
 +
 
 +
* '''Only relevant tests''' Full testing a code is very difficult and requires a very large effort. So usually one would disappointed in the way and stops testing. So first try to perform the relevant tests for the parts that are more fragile.
 +
 
 +
* '''Make a test for each bug''' If you find a bug it means that your relevant tests are not enough. So make a new test which crashes by the bug and then correct the bug

Revision as of 10:08, 9 September 2016

Usually the first question of a new developer entering for the first time to a large project and especially an open source one is: "how can I be sure that the changes by other person won't affect or destroy my part?" One answer would be a good structure and division of the code is the key. But even with a perfect structure one should protect its developments by providing tests which shows the correct function of its parts.

The testing mechanism in Kratos helps developers to create tests during their developments in a systematic way and gives the possibility to rerun them afterward. So after any change in the code one can run these tests to verify if they are not failing. In this way any new development should develop new tests and should also verify if all existing tests are OK. In an extreme approach, for any new development, one would create a test for that feature (which fails due to the lack of the feature) and then develops the code implementing that feature.


Good Practice in Testing

There are a set of thumb rules for writing good tests:

  • Test one thing if a test does different things (like "TestModelPart") a failure gives less information and a debugging would be needed to see where is the failure and why. But if it only tests one thing then the failure says that in the first glance. (like "TestInitializingModelPart Failed")
  • Faster is better running a slow test would be tedious for the developers and they would avoid long tests. So an effort should be made to find an implement a fast test.
  • Only relevant tests Full testing a code is very difficult and requires a very large effort. So usually one would disappointed in the way and stops testing. So first try to perform the relevant tests for the parts that are more fragile.
  • Make a test for each bug If you find a bug it means that your relevant tests are not enough. So make a new test which crashes by the bug and then correct the bug
Personal tools
Categories