SPaMCAST 595 – Unit Testing Principles, An Interview with Vladimir Khorikov

http://www.spamcast.net

Play Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

The SPaMCAST 595 features our interview with Vladimir Khorikov. Vladimir and I geeked out on unit testing and his new book, Unit Testing Principles, Practices, and Patterns. Our conversations covered the gamut with a discussion of writing from first principles, understanding and tuning the signal-to-noise ratio in unit testing, and tests that are better at proving the negative than the positive. 

 

Are Integration Testing and Unit Testing, Different?

USA border crossing

Are unit and integration testing the same things masquerading under a different name? No. Unit testing is a process in which a developer tests a very specific self-contained function all by itself, whereas we have defined integration testing as testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements. Unit testing and integration testing are fundamentally different forms of testing.  There are three major differences.

Boundaries: All levels of integration testing cross boundaries either between classes, functions or components.  The goal is to determine if the parts of the application fit together and perform as expected.  Unit tests focused on the performance of a single function by definition can’t cross boundaries and do not test dependencies outside of the function being tested.

Scope: A unit test is focused on answering a single question: Based on the test input, does the specific function perform as expected? An example of a simple unit test might be, “if I put a number in a field that only accepts letters, do I get an error?” Because integration tests reflect the interaction between functions or components, they must answer several questions. For example, in Test Driven Development: An example of TDD with ATDD and BDD attributes, we described a simple beer glass collection tracking application. In the application, the user enters the glass being collected into a screen, and after validation, the database is updated. An integration test would need to be written and performed that tests sending the information from the data entry function to the database.  The test would cover several different specific points such as, was the information sent from one module to the other, was it received by the other, and was it inserted in the database correctly.

Role Involvement: Unit testing is part of the coding process.  Occasionally I see tester doing a developer’s unit testing – this is a VERY POOR practice. At its very simplest, the coding process can be described as think, write code, see if it works, if it doesn’t work, go back to thinking. Then repeat, and if it works, commit the code and go to the next requirement. The “see if it works” step is unit testing. Integration testing in its most granular form reflects a transition between coding and validation processes. The transition means that the results need to more broadly seen and interpreted to ensure that all of the parts being developed or changed in a project fit together. Testers, business analysts, developers and sometimes business stakeholders and product owners can be part of executing, interpreting and consuming integration tests.

Unit testing and integration testing are at times easily confused, this is most true when considering integration tests focused at the connections between functions within a single component. However, if we consider whether boundaries are involved and the number of conditions/questions the test is resolving (which suggests that number of roles need to understand the results) the distinction becomes fairly stark.