unit tests faster than systems-levl tests

text/40_unit_testing.md

@@ -27,6 +27,8 @@ We have seen earlier that the user will never directly see the aspects of the so
 
 2. __Faster turnaround time.__ If a problem is found, there's no need for a build to occur, or to get into testers' hands.  The developer finds a problem when executing the unit test suite, and can immediately go back and start fixing it.  If the developer has to wait for a tea tester to look at the software, file a defect, and get assigned that defect, it may be quite a while before the developer actually fixes it.  In that time, he or she may have forgotten some implementation details, or at the very least will have probably swapped out some of the information and will require time for a context shift.  The faster a defect can be found, the faster it can be fixed.
 
+2. _Faster runtime than systems-level tests.__ A well-designed unit test will have few to no dependencies on other libraries, classes, files, etc.  This means that they can be extremely fast, with many tests taking a few milliseconds or less to execute.  By focusing on very specific parts of the code, that part of the code can be tested numerous times without the extra setup and execution time caused by other aspects of the system.
+
 3. __Developers understand their code.__ Writing tests allows the developer to understand what the expected behavior of the function is.  It also allows the developer to add tests for things that he or she knows might be problematic for a specific function.  For example, a developer may know that a sort function may not sort numeric strings correctly, because certain flags need to be set to ensure that it treats them as numbers instead of strings (so that "1000" is bigger than "99", which it would not be if the function treated them as strings, since "9" is bigger than "1").  A black-box tester may not realize that this is what is happening "under the hood" and so not think to test this particular edge case.
 
 4. __Living documentation.__ The tests provide a kind of "living documentation" to the code.  They explain what a codebase is supposed to do in a different way than the actual code and any comments or documentation for the software.  Failing tests are updated; they are either removed or changed as the software itself changes.  Unlike traditional documentation, if unit tests are executed on a regular basis (such as before being merged to baseline), then it's impossible for the tests to become obsolete.  Obsolete tests generally do not pass, and this is a giant indicator to get them fixed.