U
U
user_of_toster2021-01-05 14:38:44
JavaScript
user_of_toster, 2021-01-05 14:38:44

Examples of unit tests of a real application on express\koa?

I write tests, mocks take half a page and two hours, work with test isolation for another half an hour, at the output a test of dubious benefit, in which it is checked whether one mock really calls another mock. All found tutorials and books test calculators and sum(a, b) functions. help me find test cases for a real backend application on express\koa. Preferably with JEST.

Just do not throw, please, the tests of the express itself, I am not writing a framework.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
D
Demian Smith, 2021-01-06
@user_of_toster

Now comes the point that many programmers are not ready for: unit tests are a waste of time*.
* there are exceptions, about them below.
You yourself noticed that in general, tests are more difficult than code. Mok drives mocom. And fussing with tests takes more time than working on business code. This is a standard disease of many projects. The reason for this disease is the belief that tests somehow miraculously contribute to the quality of the application. This is not true. In some cases, tests help you write code faster and understand it faster. This mainly concerns:
- pure functions (such as the notorious sum) and general-purpose functions (for example, from lodash)
- regular expressions
Unit tests don't make sense on the so-called "glue". For example, the controller code, which, in theory, should be as simple as an ax. Usually glue is code that connects some logical nodes, while itself having trivial logic. This is about 90% of the code of modern applications. Testing the glue is just as ridiculous as testing the framework itself or node. Tests in the style of "now we will make sure that this service will call another service by passing such and such parameters to it" are extremely expensive, and in the end they do not provide any practical value. Because the test is more difficult than the glue itself, which is contrary to the postulates of TDD.
But still, you want to have a certain degree of confidence in what you are doing. For this there is:
- TypeXPrint (well, or another strongly typed language). With strong typing, we don't have to worry about the fact that somewhere in the bowels of the glue we forgot to pass a parameter or forgot to somehow convert it to another type. In general, everything that concerns "what if someone accidentally forgot" is decided by strict typing
- functional tests. But here, too, you need to be careful. For example, testing that you have "correct" HTML output is as stupid as unit testing the framework itself.
So it goes.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question