История изменений
Исправление
stevejobs,
(текущая версия)
:
проверки результата возвращаемых функций - это само собой, конечно. Кое-что, бросающее исключения, в случае невосстановимых ошибок можно не ловить (его поймает рантайм и скажет пользователю «капец, всё пропало»), в остальном всё надо аккуратно проверять. Это не доставляет никаких проблем, потому что это в рефлексах у любого не говнокодера. В конце концов, начерта нужен код, который непонятно сделал задачу или нет?
https://ru.wikipedia.org/wiki/Разработка_через_тестирование
https://ru.wikipedia.org/wiki/Модульное_тестирование
https://ru.wikipedia.org/wiki/Интеграционное_тестирование
а вот отдельно писать тестовые сценарии и организовывать test suite для модульных или интеграционных тестов, или как вариант - писать в виде test-first или полноценного TDD - вот на это может уйти под 60% времени разработки, в режиме «собеседования» или «хакатона» этого нафиг не нужно. Можно просто поинтересоваться, сможет ли афтар обмазать код тестами, если понадобится - чтобы понять, понимает ли он основы автоматчиесккого тестирования и TDD хватит нескольких минут
исключение - написание каких-нибудь парсеров. Там написание тестов и постоянная проверка парсера относительно тестового набора данных, наоборот очень ускоряет разработку. Не нужно постоянно думать «а правильно ли я написал» - можно просто давануть кнопку «запуск» и посмотреть не потухли ли «зеленые» тесты
Исходная версия
stevejobs,
:
проверки результата возвращаемых функций - это само собой, конечно. Кое-что, бросающее исключения, в случае невосстановимых ошибок можно не ловить (его поймает рантайм и скажет пользователю «капец, всё пропало»), в остальном всё надо аккуратно проверять. Это не доставляет никаких проблем, потому что это в рефлексах у любого не говнокодера. В конце концов, начерта нужен код, который непонятно сделал задачу или нет?
а вот отдельно писать тестовые сценарии и организовывать test suite для модульных или интеграционных тестов, или как вариант - писать в виде test-first или полноценного TDD - вот на это может уйти под 60% времени разработки, в режиме «собеседования» или «хакатона» этого нафиг не нужно. Можно просто поинтересоваться, сможет ли афтар обмазать код тестами, если понадобится - чтобы понять, понимает ли он основы автоматчиесккого тестирования и TDD хватит нескольких минут
исключение - написание каких-нибудь парсеров. Там написание тестов и постоянная проверка парсера относительно тестового набора данных, наоборот очень ускоряет разработку. Не нужно постоянно думать «а правильно ли я написал» - можно просто давануть кнопку «запуск» и посмотреть не потухли ли «зеленые» тесты