Что такое TDD
Что проверяют
Отличаете ли вы TDD как способ разработки от просто «у нас есть тесты». Следом обычно просят показать цикл на живом примере из iOS и уточняют, работали ли вы так на самом деле или знаете подход по книге.
Как отвечать
TDD (Test-Driven Development) описал Кент Бек: тест пишется раньше кода и задаёт, что код должен делать. Работа идёт короткими циклами «красный, зелёный, рефакторинг»:
- красный: пишете один маленький тест на следующее поведение, запускаете, он падает. Падение подтверждает, что тест вообще что-то проверяет;
- зелёный: пишете минимальный код, чтобы тест прошёл, даже если он пока некрасивый;
- рефакторинг: чистите код и тесты, прогон остаётся зелёным.
Пример из iOS: валидация формы входа во ViewModel. Первый тест проверяет, что при пустом email кнопка неактивна, следующие тесты касаются неверного формата и успешного входа. Сеть закрыта протоколом, в тесте подставляется заглушка, поэтому ViewModel проверяется без реальных запросов и без экранов.
Инструменты стоит назвать: XCTest с XCTAssertEqual, более новый Swift Testing с @Test и #expect, запуск по Cmd+U или в CI через xcodebuild test. UI-тесты на XCUITest медленные и хрупкие, по TDD их обычно не пишут, цикл строится на юнит-тестах логики.
Честно назовите цену: на старте работа идёт медленнее, а код с синглтонами и логикой внутри UIViewController под TDD почти не ложится. Выигрыш в том, что тесты появляются сразу, архитектура вынужденно получается слабо связанной, а рефакторинг перестаёт пугать.
Где спотыкаются
Называют TDD любую ситуацию с тестами. Если тесты дописаны после кода, это просто покрытие, а не TDD.
Пишут сразу большой тест на весь экран. Цикл теряет смысл, если между красным и зелёным проходит час.
Утверждают, что работали по TDD, и не могут показать ни одного цикла. Лучше честно сказать, что применяли подход к отдельным модулям, например к парсингу или расчётам, и объяснить, почему не ко всему проекту.