Люди иногда сомневаются в важности создания тестов перед созданием самого программного обеспечения. Хорошо, я сделал. Но когда я сталкиваюсь с TDD, я никогда не пропускаю тест, поскольку требования всегда меняются.
Что такое TDD?
TDD (разработка через тестирование) - это эволюционный подход к разработке, который сочетает в себе разработку сначала тестирование, когда вы пишете тест до того, как напишете достаточно производственного кода, чтобы выполнить этот тест, и рефакторинг.
Согласно одной точке зрения, целью TDD является спецификация, а не проверка (Мартин, Ньюкирк и Кесс 2003). Другими словами, это один из способов продумать свои требования или дизайн, прежде чем писать функциональный код (подразумевая, что TDD является одновременно важной техникой гибких требований и гибкого проектирования). Другая точка зрения состоит в том, что TDD - это метод программирования. Как любит говорить Рон Джеффрис, цель TDD - написать чистый, работающий код.
Существенным преимуществом TDD является то, что он позволяет делать небольшие шаги при написании программного обеспечения. Это практика, которую я продвигал годами, потому что она намного продуктивнее, чем попытки писать код большими шагами. Например, предположим, что вы добавляете новый функциональный код, компилируете и тестируете его. Скорее всего, ваши тесты будут нарушены из-за дефектов, существующих в новом коде. Эти дефекты намного легче найти, а затем исправить, если вы написали две новые строки кода, чем две тысячи.
«Сам процесс написания модульного теста - это скорее проект, чем проверка. Это также скорее акт документации, чем проверки. В процессе написания модульного теста замыкается огромное количество петель обратной связи, наименьшая из которых связана с проверкой работы », - Боб Мартин.
Короче говоря, преимущества TDD заключаются в следующем:
- Модульный программный код
- Простой рефакторинг и сопровождение кода
- Плодотворное командное сотрудничество
- Предотвращение ошибок
- Уточнение требований
Как выполнить тест TDD?
Вот несколько шагов для выполнения теста TDD:
- Написать тест
- Подтвердите, что тест не прошел
- Напишите код для прохождения теста
- Подтвердите прохождение теста
- Рефакторинг
- Повторить все шаги
TDD в проекте iOS
По сути, это так же просто, как UI Test и Unit Test. В чем разница между ними?
Модульный тест проверяет только один класс за тест. Любые объекты, с которыми классу нужно будет взаимодействовать, должны быть заменены фальшивым объектом, которым управляет тест. Если вы не вставляете поддельные объекты, у вас нет возможности узнать, является ли проваленный тест тем, что вы действительно пытались проверить, или чем-то, что он использует.
Тем временем..
Тесты пользовательского интерфейса используют специальные возможности различных платформ Apple, чтобы эффективно выдавать себя за пользователя, использующего приложение. Поэтому мы должны обязательно протестировать все элементы пользовательского интерфейса, которые мы собираемся добавить в будущем.
Например…
Например, мы собираемся создать эту страницу входа. Прежде чем создавать страницу, мы сначала создаем тест.
Здесь мы видим, что есть 3 элемента пользовательского интерфейса, которые необходимо протестировать. Это текстовое поле для электронной почты и пароля, а также кнопка «Masuk». Следовательно, мы можем протестировать эти три с помощью этой функции:
Вы можете видеть, что код проверяет все элементы пользовательского интерфейса. Он действует как настоящий пользователь, поскольку действительно нажимает на текстовое поле, вводит адрес электронной почты и пароль и нажимает кнопку «Masuk». Если вы запустите тест пользовательского интерфейса, он будет выглядеть так.
Что касается модульного теста, мы должны протестировать два условия, когда пользователь вводит правильную учетную запись для входа и неправильную.
Внедрение TDD в групповом проекте
Давайте воспользуемся тем же примером, что и выше, чтобы получить общую картину. Когда я завершаю создание тестов пользовательского интерфейса, я отправляю их в GitLab с сообщением фиксации «[КРАСНЫЙ] Страница входа в пользовательский интерфейс», а также для модульного теста.
[КРАСНЫЙ] означает, что тест не пройден, поэтому конвейер не работает. Я не написал код для прохождения теста, поэтому тест не находит никаких элементов, которые он тестирует.
Поэтому я пишу код и нажимаю на него с сообщением фиксации «[ЗЕЛЕНЫЙ] создать страницу входа» (извините, если я написал это на Bahasa).
Как вы и предполагаете, [ЗЕЛЕНЫЙ] означает, что тест прошел успешно, так как код реализации был создан.
Хотя бывают случаи, когда нам приходится заново реорганизовывать код, чтобы тест прошел успешно.
[REFACTOR] означает, что я изменяю и изменяю код реализации до тех пор, пока тест не будет успешным. Это требует усилий, но оно того стоит;)
Изменения требований неизбежны, поэтому нам нужно быть более осторожными. Мы можем сделать это, внедрив TDD в наш проект, так что он предотвращает ошибки и его легко реорганизовать и поддерживать.
