Before reading this article, I hope that those who are not familiar with TDD and MVVM will come to a brief overview through the link below🙏🏻
https://en.wikipedia.org/wiki/Test-driven_development
I’ve been doing TDD for a long time and I’m still not sure. I think the sweet talk in the book is half right and half wrong. In my opinion, the biggest attraction of TDD is spiritual victory😂 It makes development more fun. There is also some stability through test automation.
As mentioned in Kent Beck’s TDD book, there are still major difficulties in unit testing UI. However, it is now possible to unit test the UI using the ViewModel of the MVVM architecture. Of course, it is difficult to write unit tests for the entire UI, but assertions for UI flow and result values are possible.
Now how to write unit tests using ViewModel. I’ll go further and explain how to make development fun with TDD🔥
First of all, to do TDD, you need cyclical and continuous steps. You can think of it as being completed by repeating three steps: scenario definition, test code writing, and implementation. You may not get used to it at first, but it is important to get used to it through a lot of practice.
Let’s do it one by one through animal friends examples🐶🐼🐻
Scenario Definition
- If you click the ⬆️ button, the animal friends move upward by a certain amount.
- The amount of change the animal friends moved is displayed as centerX and centerY values on the label.
I’m going to create a test class named ControlPannelViewModelTest and comment with the scenario I defined.
Write test code
Assuming that the defined scenario works, you should imagine the flow of user actions and logic and write a test scenario.
- Bind the output properties to be asserted.
- The user clicks the ⬆️ button.
- A button click event is occurred, and it is passed to the ViewModel.
- The output properties that will operate the UI in the ViewModel are updated and sent.
- Assert the changed output properties.
You should practice simulating all of this behavior in your head and putting it into test code.
n the code above, ControlPannelViewModel is a class that hasn’t been written yet. You have to hypnotize that you have an implementation that will actually work and write test code. This also takes a lot of practice.
Let’s run the test code at this point. It doesn’t compile and it’s a mess ☠️ It’s normal, don’t worry😃
Implementation
Resolve compilation errors
Once you’ve written the test code, the next step is to resolve the compilation errors. You have to write an undefined class and add properties and methods.
If you run the test after resolving all the compilation errors, it will show that the test passed unexpectedly. Isn’t it strange? We didn’t implement anything…😳
Assertion is not executed until the end of the test execution, so it looks like the test passed, but it is in a failed state. To solve this problem, I will write a few lines of code for an asynchronous test.
Briefly, expectation is an API written to handle failure when the fullfill count is not satisfied within the timeout time. The test actually fails as shown below.
Implementation complete
Now, if the logic is implemented in the implementation to satisfy the value expected by the Assertion, and the test succeeds, it is complete.
The test will be successful and you will receive shiny green medals❇️❇️ This is the fun of TDD. Spirit Victory ✌️✌️
As above, if you gradually perform the scenario definition > test code writing > implementation, the function will be completed, you will feel better, and you will get test automation products as an added bonus. This is Extreme Programming
Conclusion
If you are using MVVM and you are aiming to automate UI tests, I think the method I gave you will be useful. If you want to win mentally as a bonus👍
