Recently I am responsible for a small book review project in the school library. The project is based on Java, because the subject studied C before and had no Java experience before starting. I have only been exposed to it for about a month. I have to say that it is really good that Java's open source ecosystem is comparable to Python. Now I encounter a problem when writing Java. The first thing is to go to Github to find tools. . However, one problem caused by this is that you almost don’t have to use your own brain, and these mainstream Java frameworks are basically supported by spring. In this way, the entire project becomes only a simple crud operation.
The whole project seems to be simple now (I haven’t used things like ehcache and redis for caching yet, and I haven’t considered the performance of concurrency). I used the small wheels I built before, such as After user authentication and the like are all replaced by spring security, there are also good tools like druid
for database monitoring. It feels like I wrote almost nothing in the entire project. Things like controller/service/dao/model/util are all spring family buckets. In this case, how should I write unit tests? It feels like there is nothing to write.
Because I have seen some old projects of senior students, there are no tests and documents. Although the project is relatively simple, it seems to be a headache, so I still want to standardize it as much as possible. Although I will not engage in Java in the future, it can also benefit me. The people behind. .
ps: This question is not a complaint topic. There are many knowledge points in Java that need to be learned, such as the source code of various excellent frameworks and jvm. If spring has a bug without looking at the source code, you can only stackoverflow.
You can consider testing each function of the controller layer. Entering from the controller can avoid overly complex object dependencies.
Just writing about business is of no use. . . Algorithms and design ideas are the most important and most valuable. . .
Test safety and performance. . .