Fools Don't Write Unit Tests

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

“У нас нет времени писать модульные тесты” или “У нас нет бюджета для модульного тестирования” — это жалобы, которые я часто слышу. Иногда звучит так: “Мы не используем TDD, поэтому у нас нет модульных тестов”, или даже “TDD слишком дорог для нас сейчас”. Я уверен, вы слышали это или даже сами говорили. Мне это не имеет смысла. Я не понимаю логики. По моему пониманию, модульное тестирование — это не продукт; это инструмент. Вы используете тесты, чтобы разрабатывать продукт быстрее и лучше. Как можно сказать, что у вас нет времени использовать инструмент, который делает вашу работу быстрее? Позвольте мне показать вам, как.

С использованием TDD или без него, модульный тест — это модульный тест. Вы либо создаете его до основной части кода, либо после нее.

Модульный тест — это инструмент, который помогает вам, разработчику программного обеспечения, “запускать” ваш код и видеть, как он работает. Как еще можно проверить, работает ли он? Когда я слышу “У меня нет времени на модульные тесты”, мой следующий вопрос: “Как вы тестировали свой код?”

Я серьезно не могу понять, как можно написать что-то и потом не протестировать это. Ну, если вы получаете зарплату ежемесячно и никому на самом деле нет дела до ваших результатов. Если вам действительно важно то программное обеспечение, которое вы производите, то вам интересно увидеть его в действии, верно?

Итак, как вы это делаете?

Если это одностраничный веб-сайт на PHP, вы, возможно, можете запустить его локально на Apache, изменить его на диске и запускать команду Cmd+R много раз. Это может сработать для простого куска кода и только для вас, одного разработчика. Но я слышу этот аргумент “У меня нет времени” от программистов, работающих над корпоративными системами. Как вы тестируете свой код?

Я бы сравнил модульные тесты с классами ООП. Вы можете разработать всё приложение в одном классе с несколькими тысячами методов. Вы сэкономите время на создании других классов, структуризации их, думая о связях между ними и т.д. Это будет один файл .java на 20 000 строк. И вы скажете, что “у вас не было времени создавать классы”, верно? Что мы скажем о таком продукте и его авторе? Правильно, мы скажем, что он или она просто глупый. И это не имеет никакого отношения к времени или бюджету. Такой программист просто не знает, как использовать инструменты объектно-ориентированного программирования, такие как инкапсуляция, наследование, полиморфизм, интерфейсы, перегрузка методов и т.д. Это не связано с временем или бюджетом; это связано с навыками и дисциплиной.

То же самое верно и для модульных тестов. Если вы создаете код без модульных тестов, он может работать, как тот монструозный класс с 20 000 строками, но качество вашего продукта будет очень низким. И не потому, что у вас не было времени написать модульные тесты, а потому что вы не знали, как это сделать.

Так что каждый раз, когда я слышу “У меня не было времени на модульное тестирование”, я понимаю, что вы просто не знали, как это сделать, и пытаетесь замаскировать этот факт ложными оправданиями. Это, мягко говоря, не профессионально.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-15 at 07:15

sixnines availability badge   GitHub stars