| Previous | Next |
| Speaker's notes: | From http://c2.com/cgi/wiki?StandardDefinitionOfUnitTest: IEEE Standard Computer Dictionary defines unit testing as "Testing of individual hardware or software units or groups of related units." Outside of the professional "quality assurance" testing community, the term "unit testing" covers just about everything the programmer may do (or may not do ;-) to test their code -- before "integration testing." |
|---|
| Speaker's notes: | A unit test is usually written by the developer who wrote the code unit. |
|---|
| Speaker's notes: | This is not always true; it depends on the methodology and policy of the development group. I'll speak more about isolation later. |
|---|
| Speaker's notes: | Test all non-trivial cases. You normally won't write tests for trivial accessors (setters and getters), for example. Just remember that when you modify a trivial setter and add complex logic, you should also add a test case to verify the new behavior. In Python, this case includes modifications to __setattr__ and __getattr__. I've also been told "test everything that could fail." |
|---|
| Speaker's notes: | In a dynamic language like Python, you should test to see what happens when the arguments are of the wrong type, for example. Each distinct condition that could throw an exception should also be tested to verify the exception type. Client code may be expecting a specific exception type, and if your code starts throwing a different exception type on the same condition, you'll break those users of your code. |
|---|
| Speaker's notes: | Having 1000 unit tests won't help if developers have to run them by hand one at a time. Unit tests are only useful if a developer can easily run all (or a subset) of the tests with a single command or button press. |
|---|
| Speaker's notes: | Even if you have a QA department that does application testing, unit testing is still important and valuable. If nothing else, it should reduce the number of bugs in the code given to QA, reducing QA time or permitting them to focus on different aspects of testing (ease of use, user expectations, etc.). |
|---|
| Speaker's notes: | In unit testing, you're just verifying that a single unit works according to expectations. It could be that the user of the unit is manipulating it incorrectly or is expecting different behavior. Testing that all of the components work together correctly is often done separately. Note that if you enforce less isolation among layers during some or all of your unit testing, your unit tests may provide some level of integration testing. Of course, in that case, the failure of a unit test may not necessarily indicate an error in the unit it was testing. |
|---|
| Speaker's notes: | After starting the unit tests, a developer should be able to let the tests run in the background without having to supply any extra input. That way, developers can easily run tests while writing code. |
|---|