...
With this wonderful toolset and the philosophy of TDD, there is an approach that is missing. What do you do when you are faced with a problem that is foreign to you and have very little understanding of the API required to solve the problem? Pre -unit test and TDD “unit testing and TDD” I would begin by hacking some code together and using static public void main() as the testing ground, with the code growing ever more complex with each piece of new understanding. But during the COVID lockdown across the world, I decided to enter a new phase of learning (every day is a school day lol). I wanted to follow a TDD approach to learning how to use an API and at the same time develop the solution.
| Info |
|---|
In this talk, I will be using Java and make a number of assumptions - you know what a test double is, and how to write a JUnit test case. What I say here is equally applicable if you are a C++, C# or another language developer. Test doubles are an integral part of your testing toolkit. There are five types of test doubles that we commonly speak about, Dummy, Fake, Mock, Spy, Stub. Martin Fowler summarises them beautifully here In this section, I will focus on Stubs, Mocks, and Spies. It is a commonly held view that a Dummy, Fake, Spy, and Stub are Mocks. They are not. Each one is a type-of Test Double with a very specific purpose. A Mock and Spy can be categorized as interaction Test Doubles - they focus on peering on the inside of CUT to ensure that it behaves as expected and that the CUT interacts with the Mock and Spy as expected. However, Mocks are very useful for stateful testing using expectations. There are lots of Mocking frameworks out there, I am using Mockito in my discussion. |
...
Test one method in a class
Not be an integration test
Execute quickly
Be independent of other unit tests, in other words, isolated
Does not interact with a non-in-memory database
Does not perform any file IO
Does not perform any network IO
The scope of the test should be between the Unit Test , and the CUT, and NOT any periphery objects to the CUT, but not including its grand children
Points 5, 6, and 7 are of important interest here. Unit tests are ultimately deployed to a build server. In doing so there are no guarantees that tests that exhibit these capabilities will pass because the database will not be accessible, the file system will more likely be blocked, files may have moved or changed, and networking will be restricted if not totally blocked.
...
So here is the problem we will walk through and discuss - an application that reads a text file and stores the contents of that file in a database. Each line in the text file is stored as a row in a database table. The schema class model for the database will be
...
The testing environment will look like this
...