R(
они считают что это самые настоящие юнит тесты и попросили меня пруфоф =) почему это не так я дал обьяснение что такое юнит тесты и попросил дать пруфы почему это юнит тесты =) раз дело у пруфах пошло
https://en.wikipedia.org/wiki/Unit_testing#Limitations_and_disadvantages
Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects,[5] fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Because some units may have references to other units, testing a single unit can frequently spill over into testing another unit. A common example of this is units that depend on a database: in order to test the unit, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own unit boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when such test cases fail, it may be unclear which component is causing the failure. Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher-quality unit that is also more maintainable.
Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects,[5] fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Because some units may have references to other units, testing a single unit can frequently spill over into testing another unit. A common example of this is units that depend on a database: in order to test the unit, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own unit boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when such test cases fail, it may be unclear which component is causing the failure. Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher-quality unit that is also more maintainable.
