Пост​​Мы уже общались об автоматическом тестировании и его вкладе в процесс разработки и влиянии на архитектуру. Плюсы, мину…

​​Мы уже общались об автоматическом тестировании и его вкладе в процесс разработки и влиянии на архитектуру. Плюсы, минусы, подводные камни. Даже (предельно скучно) написали небольшой алгоритм пользуясь принципами TDD. Беда в том, что продукты редко ограничиваются такими легко-тестируемыми алгоритмами, и намного чаще состоят из огромных и сложных компонентов, которые между собой взаимодействуют. Так просто не протестируешь поведение, работающее с базой данных, или с удаленным сервером, или использующее многопоточность, или с множеством одновременных запросов от клиентов, или «абсолютно нетестируемые» продукты, вроде компьютерных игр. Даже если мы возьмем простой случай обычного пользовательского интерфейса, как писать unit-тесты чтобы удостоверится, что все работает по плану? Более того, часто возникает потребность покрыть тестами уже существующий код. А он обычно не блещет красотой, так как изначально не был написан с расчетом на то, что кто-то возьмется его покрывать тестами? Как тогда покрыть тестами поведение, которое использует статические классы, изменяемые глобальные состояния, синглтоны, локаторы сервисов и прочее. Об этом мы с вами будем говорить на паре завтра, в 10:30 в Белке (библиотека КПИ). Если вы не студент КПИ - не забудьте взять с собой документы