Don’t get bogged down by unit tests! Don’t get bogged down by unit tests!! Don’t get bogged down by unit tests!!
An overview of the
Unit test is to check the correctness of the smallest unit of the system (usually function, class or module). We use unit testing to optimize code quality and improve development efficiency, not to blindly pursue 100% code coverage, which makes no sense.
Priority unit testing
If you write the code, to write unit tests, it must be a unit test for unit tests, you must feel the benefits of it, or you will say I have a unit test, reconstruction or reform in the late I will be more confident, more than one occasion I’ve heard this statement, the unit test validation is the smallest unit, they are so easy to be changed. Most of the time the unit tests of your refactored code will have to be rewritten.
I think the benefit of unit testing is that I don’t maintain unit tests until I actually use them (debugging bugs, refactoring the business) in the early stages, even after business development is complete. Of course, the benefits of maintaining unit tests over a long period of time are obvious, and when the business changes, I become more confident just by running unit tests. But the maintenance cost is too high, basically equal to the maintenance cost of the business, I can’t be weighed down by unit testing!!
All for design
If you have a design habit before you write code, like drawing on scratch paper or thinking about it in your head. I’ve seen a colleague who takes a moment before writing code with a serious frown and a pensive grin, and I know he has a good habit. If that’s you, why not use unit tests, instead of scribbling paper or your teeth, to compare drawings with code? For example, write casually like this:
In the first stage, pseudo-code is used to clarify the logic and business. This stage can be omitted, but I still suggest that you can try for a period of time at the beginning, that is, compare to draw, how to write, without norms and format constraints, than in the mind to the idea to cool much.
Now, we need to write real code, because we can’t write business code at this stage, so we need to define the abstraction first. The diagram below:
Design is abstraction, and unit testing teaches us to define abstraction. The interface in the figure above is not designed first, but when writing unit tests, I define what is missing and what needs to be tested. Programming for abstraction, not abstraction for abstraction’s sake, we are not abstracting it forcibly based on existing implementation classes. Instead, we need to build the blueprint with abstraction, which is the thick lines in the early stage, and on this basis, the details in the later stage are gradually improved.
All for efficiency
Now that you have abstraction, all you need to do is get someone else to implement it, which shouldn’t be too difficult. Just write the business code, run the unit tests, and if it doesn’t pass, change the code and run the tests. If so, proceed to the next function implementation. This saves a lot of running and debugging time, which should feel great at this stage.
In addition, the View layer cannot be tested only in the native Java virtual machine, but since the View layer is really simple and just provides parameters, or basic capabilities, this part of the code is not a problem. This is exactly why Google launched MVP, decoupling the View layer abstraction to enable efficient unit testing.
Here is the unit test code. Since we haven’t debugged it, there may be some problems, but the general flow is correct:
LoginModel.kt
LoginPresenter.kt
The last
If you know how to use unit tests, you love them.