Testing the right way
A lot of times we find people testing their application incorrectly. This includes myself until few months ago. In order to have robust testing, it is very important that we understand what are we testing. I will demonstrate this with a few scenarios below:
1. Front end Development : A front end developer should focus their testing only on the front end. For example, if there is a button on a page which updates a piece of information, then the test scope should be confined by the front end change and should be isolated from any backend dependencies such as whether the information was actually saved by backend. This test case should look like :
- Open web page
- enter information X
- click “Update” button
- Assert “Successful” text is shown.
2. Backend development : Similarly, backend code should focus on testing only the backend portion . So, here the test should look something like :
- Open connection to backend.
- execute API with information X
- Assert “X” is updated
This is the only way you can guarantee 100% that both component are actually tested.
3. Mixed : If we intermingle the scopes and come up with something like :
- Open web page
- Update the information X.
- Wait for the application to come back.
- Assert whether ‘X’ was updated.
The above is doable but becomes a victim of dependency on network, availability of web services and latency or HTTP responses, which are not under our control. The result would be flaky, hard to maintain and unreliable tests. Such tests fall into a category of integration tests and serve their purpose only if you have very robust and fail-safe code with enough time-lag to address network and system delays. There is a place for such tests but they should be fewer as advised by the principles of the test pyramid.
Mocks
Mocks play a very important role in testing. How are mocks used? Let us go through the scenarios. In the first scenario for front end test, mocks will only contain the response which backend API is supposed to return. So instead of actually calling the backend API, you would just assume the response and save it in a file called mock or fixture and perform your front end testing using that.
In the second scenario it will be other way round. Mocks will contain the mock information that front end is supposed to send. Basically, you are testing API to provide an assertion “I don’t care about where you call me from, when you call me (correctly), I will update this piece of information” .
Mock Servers
A lot of mock servers are available which provide a mocking infrastructure and a plug-and-play tuning with your tests. But a lot of times, we use these mock servers incorrectly, and expect them to behave in a certain way, so that our tests are green. But trust me, a mock server is just a convenience for you to not create fixtures manually. Mock servers do not and should not have the logic to convert mocked responses based on a test logic. If that happens, then mock server is not a mock server. It is something else.
Summary
Proper testing involves its own design principles and has to be thought through in detail. It involves making a mental model of your app and thinking what you want to be sure of regarding your application. If you understand the scope of your app and boundaries of control you have, then testing becomes easy. Fortunately, we have a lot of frameworks which do ground work for us. Most modern languages such as Java, Node, iOS, Ruby on Rails, or Python come with great testing frameworks. If we use these tools well and follow the guidelines mentioned here, we can create easy to use, maintainable and robust test cases.
