We often discuss some issues in appworks, such as: what tools are used, what products are used, how marketing is required, who to cooperate with, how to cooperate, when to increase capital, how much money to get... And so on. These questions often do not have a certain answer and must be determined by the situation. But the more I don't have a standard answer, the more I think we should discuss it. In this way, we can help entrepreneurs define the most suitable processing methods based on their own situations.
For coding, "Do you want to write test" is one of these problems. My personal opinion is that you do not have to write test if you want to create an MVP that is very simple and out of use. If the logic is complex, maintenance is necessary in the future, or you need to work with others, you must force yourself to write test.
This is definitely not just about integrity, logic, or responsibility as an engineer. If you don't write test, it's about having a hard time with yourself-like good comment/documentation, in the future, you will spend more time figuring out your original code. When someone else wants to use your stuff, you must spend more time explaining it to him, isn't that just a problem with yourself?
I have to admit that I am not an expert in deciding when to write test and How to Write test. But I have read an article well written today. I will share it with you here.
- Test allows you to useProgramChallenge your program skill-- As an engineer, what everyone hates most is continuous manual testing. Why not write these as programs? In addition, the best way to progress is to attack your shield with your own spear. In this way, your program's skill will grow by leaps and bounds.
- Test allows you to talk to your program and yourself.-- When you come back to view your own test after a few minutes, you will review your original logic-is it really necessary to handle such complicated errors? Is this object independent... Wait, and check whether the program you wrote matches the architecture of the entire system.
- Test reminds you how many lines are used to measure the program, rather than how many lines are written.-- Remember, the best program code is not the program code!
- A good test design also includes a good test Annotation-- If you write a test, it is easier for others to understand your program and how to introduce it to you.
- Test allows you to view the code written by others-- In the same way, if you write a test, you can better understand the code written by others, and everyone will make better progress.
The above are some ideas about writing test, hoping that you can better recognize the value of test code. Maybe you have more interesting experiences? You are welcome to leave a message to share with us.