Flutter for Enterprise | Unit Testing Usecase [2/2]

Test Driven Development

1. Add a test case in support to the feature/change request.

2. Write the minimum code to make the test case pass.

3. Adjust with the rest of production code through refactoring.

Unit Test

For example, suppose you want to go from place ‘A’ to place ‘B’ and you went by train. If you write test case to validate this logic using test last approach then you’ll end up including the mode of transportation as a part of the behavior that you want to validate. However that is just an implementation detail that you’ve used. Different people might use different mode of transportation to reach the same destination from the same starting point.

For example, let us consider a SUT for which we want to validate its behavior. Just like any other application, it performs IO operation to retrieve and send data. IO operation are slow in nature and since the behavior we want to validate is IO dependent, we have two possible choices, either to perform IO operation or imitate IO operation. If we perform IO operation then it will significantly increase the time it requires to complete the unit test, which is against its core principle. So we resort to using test double to imitate the IO operation and provide dummy IO interaction to validate our behavior.

Considering the above example, we conclude to use the test double to imitate IO operations. Had the dependent object responsible for IO been created within the SUT, we could never substitute with a test double. So, this can only be realized if we can pass the instance of the test double externally and avoid its creation inside our SUT which ultimately enforces the dependency injection pattern.

First Step in TDD cycle
Second and Third Step in TDD cycle
Start of next iteration of TDD cycle with new test case added

“Why so much hard-work when we could have just write the proper implementation in the first place?”

For example, your newly recruited team member may be unaware about the current implemented domain logic. In this scenario, the test case serves as a technical document and explains the domain in a step-by-step manner. It will also allow them to modify with confidence as the existing test case prevents any potential unwanted behavior change of the application.

“Placing a block on top of stack by picking an existing block from underneath the structure is roughly equivalent to adding/changing a feature during software development.“

If the process of adding a new block adheres to TDD then the test case here serves as a guideline that never allows a mispositioned block to be placed on top of the stack and impose a risk to the entire structure. So even if our structure seems wicked, the risk of falling is drastically reduced.

EXAMPLE : As a feature, we need to allow customers to calculate EMI for the requested loan.

“If rate can be fetched then EMI needs be calculated and shown to the user otherwise conclude as an error.”

“EMI must be 150391.64490861617 for amount = 10,000 , rate = 15%, time =24 months”

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store