Разработка через тестирование: Что, если ошибка находится в интерфейсе?

Одна из практик TDD - это использование детских шагов (которые вначале могут быть очень скучными), то есть использование действительно маленьких шагов, чтобы вы могли понять свою проблемную область и найти хорошее и удовлетворительное решение вашей проблемы.

Если вы уже знаете дизайн своего приложения, вы вообще не занимаетесь TDD. Мы должны разработать его во время проведения ваших тестов.

Поэтому я предлагаю вам сконцентрироваться на маленьких шагах, чтобы получить правильный тестируемый дизайн

Я не думаю, что какой-либо настоящий практикующий TDD будет утверждать, что он полностью исключает возможность ошибки или регрессии.

Помните, что TDD в основном касается дизайна а не о тестировании или контроле качества. Сказать «все мои тесты пройдены» не означает «я закончил».

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

При правильном применении TDD действительно должен сделать вашу жизнь намного проще перед лицом меняющихся требований.

По моему опыту, код, который легко протестировать, - это код, который ортогонален другим подсистемам и который имеет четко определенные интерфейсы. Учитывая такую ​​отправную точку, намного проще переписать значительные части вашего приложения, поскольку вы можете работать с уверенностью, зная, что а) ваши изменения будут изолированы для нескольких подсистем, и б) любая поломка быстро обнаружится как неудачные тесты .

Если, с другой стороны, вы просто вводите модульные тесты в свой код после того, как он был разработан, то у вас могут возникнуть проблемы при изменении требований. Есть разница между тестами, которые быстро терпят неудачу при изменении подсистем (потому что они эффективно сигнализируют о регрессиях), и теми, которые являются хрупкими, потому что они зависят от слишком многих несвязанных частей состояния системы. Первое должно быть исправлено с помощью нескольких строк кода, а второе может заставить вас часами чесать голову, пытаясь разгадать их.

Единственный верный ответ - это зависит от .

• Есть способы сделать TDD неправильно, например что это не вписывается в ваш окружающей среды и ест усилия с минимальная выгода.
• Есть способы сделать TDD правильно, например что это снижает затраты и увеличивает качество.
• Есть способы кое-что похоже, но отличается от TDD, который может или не может называться TDD, и может или не может быть более подходящим в ваша конкретная ситуация.

Это странная особенность рынка программных инструментов и экспертов в том, что для максимизации дохода тех, кто их продвигает, они всегда пишутся так, как будто они каким-то образом применимы ко «всему программному обеспечению».

По правде говоря, «программное обеспечение» столь же разнообразно, как и «аппаратное обеспечение», и никому не придет в голову покупать книгу по строительству мостов, чтобы спроектировать электронное устройство или построить садовый сарай.

Я думаю, у вас есть некоторые неправильные представления о TDD. Для хорошего объяснения и примера того, что это такое и как его использовать, я рекомендую прочитать Кент Бек Test-Driven Development: By Example .

Вот еще несколько комментариев, которые могут помочь вам понять, что TDD - это и почему некоторые люди клянутся этим:

«Как совместить разработку, основанную на тестировании, с дизайном, который должен измениться, чтобы отразить растущее понимание проблемного пространства?»

• TDD - это метод исследования проблемного пространства и создания и развития дизайна, отвечающего вашим потребностям. TDD - это не то, чем вы занимаетесь в дополнение к дизайну; он занимается дизайном.

«Как сделать так, чтобы практика TDD работала на вас, а не против вас?»

• TDD - это не «вдвое больше работы» как не делаю TDD. Да, вы напишете много тестов, но на самом деле это не займет много времени, и усилия не будут потрачены зря. Вам нужно как-то протестировать свой код, верно? Запускать автоматические тесты намного быстрее, чем ручное тестирование всякий раз, когда вы что-то меняете.

• Многие руководства по TDD представляют очень подробные тесты каждого метода каждого класса. В реальной жизни люди этого не делают. Глупо писать тест для каждого сеттера, каждого получателя и так далее. Книга Бека хорошо показывает, как использовать TDD для быстрого проектирования и реализации чего-либо, замедляясь до «маленьких шажков» только тогда, когда все становится сложно. Подробнее см. Насколько глубоки ваши модульные тесты .

• TDD - это не регрессионное тестирование. TDD - это думать, прежде чем писать код. Но наличие регрессионных тестов - хорошее побочное преимущество. Они не гарантируют, что код никогда не сломается, но они очень помогают.

• Когда вы вносите изменения, которые приводят к сбою тестов, это неплохо; это ценный отзыв. Дизайн действительно меняется, и ваши тесты не высечены на камне. Если ваш дизайн настолько изменился, что некоторые тесты больше не действительны, просто выбросьте их. Напишите новые тесты, чтобы быть уверенным в новом дизайне.

это уже не простой вопрос нырять и исправлять "ошибку", но вы также должны переписать все

Основное кредо TDD - избегать дублирования как в производственном коде, так и в тестовом коде. Если единственное изменение дизайна означает, что вам нужно переписать все, вы не выполняли TDD (или делали это совсем неправильно).

В идеале, в хорошо спроектированной системе с надлежащим разделением задач изменения дизайна являются локальными, точно так же, как изменения реализации. Хотя реальный мир редко бывает идеальным, вы все же обычно получаете что-то среднее: вам нужно изменить некоторые производственного кода и некоторые тесты, но не все, и изменения в основном просты и могут даже выполняется автоматически с помощью инструментов рефакторинга.

Кодирование чего-либо, не зная, что будет лучше всего работать в пользовательском интерфейсе, и в то же время писать unittests. На это уходит очень много времени. Лучше начать с создания некоторых прототипов графического интерфейса, чтобы обеспечить правильное взаимодействие ... а затем переписать его с помощью модульных тестов (если ваш работодатель позволяет вам).

Непрерывная интеграция (CI) - это один из ключей. Если ваши тесты запускаются автоматически каждый раз, когда вы регистрируетесь в системе контроля версий (и все остальные видят это, если они терпят неудачу), легче избежать «устаревших» тестов и оставаться в плюсе.

Как сказал г-н Диас, Baby Steps - это важный. Вы делаете небольшой рефакторинг, запускаете свои тесты. Если тесты дают сбой, вы немедленно определяете, ожидается ли это (изменение дизайна) или неудачный рефакторинг. Когда тесты действительно независимы (приходит с практикой), это редко бывает очень сложно. Развивайте свой дизайн медленно.

См. Также http://gotit-tracker.blogspot.com/2005/11/notes-on-pragmatic-unit-testing.html - и обязательно купите книгу!

РЕДАКТИРОВАТЬ: Возможно, я неправильно смотрю на это. Скажем, у вас есть устаревшая кодовая база, которую вы хотите изменить. Первое, что я попытаюсь сделать, это добавить тесты для текущего поведения. Рефакторинг без тестов рискован - вы можете изменить поведение. После этого я начинал очищать дизайн небольшими шагами, выполняя свои модульные тесты после каждого шага. Это придало бы мне уверенности, что мои изменения ничего не ломают.

В какой-то момент API может измениться. Это было бы критическим изменением - клиентов нужно было бы обновить. Тесты скажут мне это - и это хорошо, потому что мне придется обновить всех существующих клиентов (включая тесты).

Это не TDD. Но идея та же - тесты являются спецификациями поведения (да, я использую BDD), и они дают мне уверенность в необходимости рефакторинга реализации, гарантируя, что я сохраню поведение (а также сообщая мне, когда я поменять интерфейс).

На практике я обнаружил, что TDD дает мне немедленную обратную связь о плохом дизайне интерфейса. Я мой первый клиент - я знаю, когда мой API трудно использовать.

Мы склонны делать меньше дизайна заранее с TDD, зная, что это может измениться. Я выполнял проекты через огромные колебания (это веб-приложение, нет, это сервер RESTful, нет, это бот). Тесты дают мне возможность рефакторинга, реструктуризации и развития вашего кода намного проще, чем непроверенный код. Хотя это кажется противоречивым, это правда - даже если у вас больше кода, вы можете вносить серьезные изменения и иметь уверенность , что в существующей функциональности ничего не сломалось.

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