Tagged: Acceptance Testing
Unit. Integration. Acceptance.
Confused about which kind test to implement in your development process?
The following types of tests are complementary. Some of them address the system from the user’s perspective, others form the developer’s point of view. This is why I don’t know many practical cases where focusing on one type of testing is sufficient.
Unit Testing
As the name suggests this type of test is performed for the smallest units of source code.
- Simple as possible
- Repeatable
- Consistent
- Fast execution
- Easy to debug
- Few external factors
Restrictions:
- Don’t access the network
- Don’t spin up a thread
- Don’t use the file system
- Don’t use the database
- … in short, don’t use any dependency when it’s initialization or manipulation is not straight forward or it’s time consuming. If any such dependency is needed in your unit tests, mocking is the way to go.
The shortcoming of this type of testing is that it addresses small blocks of functionality. The unit tests don’ t cover the aspects of how the entire system performs.
Integration Testing
- Can use threads
- Can use system dependent values that change dynamically (such as DateTime.Now)
- Can use external dependencies
- Can access the network
- …can use whatever is required to ensure the correct functionality of all the code, in whatever production environment.
Acceptance Testing
The tests are made based upon the user stories and address the system as a black-box If the acceptance tests pass, it means that the program meets the user requirements.
Of course, there are a lot more type of tests than the ones this post concerns. However, when building the foundation of testing the source code, I think a good starting point is provided by the above three.