Q. Кент Бек использует список, который он добавляет и вычеркивает, чтобы направлять процесс разработки. Как вы составляете такой список? Изначально у меня было несколько элементов, таких как «сервер должен запуститься», «сервер должен прерваться, если канал недоступен» и т. Д., Но они смешались и, наконец, теперь это просто что-то вроде «клиент должен иметь возможность подключиться к серверу» встроенный запуск сервера и т. д.).
Я начинаю с того, что выбираю все, что могу проверить. В вашем примере вы выбрали «запуск сервера».
Server starts
Теперь я ищу любой более простой тест, который я мог бы написать. Что-то с меньшим разбросом и меньшим количеством движущихся частей. Я мог бы рассмотреть "настроенный сервер правильно", например.
Configured server correctly
Server starts
Действительно, «запуск сервера» зависит от «правильно настроенного сервера», поэтому я делаю эту ссылку понятной.
Configured server correctly
Server starts if configured correctly
Теперь я ищу варианты. Я спрашиваю: «Что может пойти не так?» Я мог неправильно настроить сервер. Сколько разных способов это имеет значение? Каждый из них делает тест. Как сервер может не запуститься, даже если я настроил его правильно? Каждый случай этого делает тест.
Q. Как вы справляетесь с переписывает? Сначала я выбрал полудуплексную систему, основанную на именованных каналах, чтобы я мог разработать логику приложения на своем собственном компьютере, а затем добавить часть связи USB. Он перешел, чтобы стать объектом на основе сокетов, а затем перешел от использования сырых сокетов к использованию модуля Python SocketServer. Каждый раз, когда что-то менялось, я обнаруживал, что мне приходится переписывать значительную часть тестов, что раздражало. Я полагал, что тесты будут несколько неизменным руководством во время моей разработки. Им просто хотелось больше кода для обработки.
Когда я меняю поведение, я считаю разумным менять тесты и даже сначала менять их! Если мне нужно изменить тесты, которые не проверяют напрямую поведение, которое я нахожусь в процессе изменения, это признак того, что мои тесты зависят от слишком большого количества различных поведений. Это интеграционные тесты, которые я считаю аферами. (Google "Интеграционные тесты - это афера")
Q. Мне нужен был клиент и сервер для связи по каналу для проверки любой из сторон. Я мог бы издеваться над одной из сторон, чтобы проверить другую, но тогда весь канал не был бы проверен, и я боюсь, что пропущу это. Это умаляет весь красный / зеленый / ритм рефакторинга. Это просто недостаток опыта или я что-то не так делаю?
Если я создаю клиента, сервер и канал, то я пытаюсь проверить каждый из них изолированно. Я начинаю с клиента, и когда я тестирую его, я решаю, как должен себя вести сервер и канал. Затем я реализую канал и сервер, чтобы они соответствовали нужному мне поведению. При проверке клиента я заглушаю канал; при проверке сервера я издеваюсь по каналу; при проверке канала я заглушаю и высмеиваю как клиента, так и сервера. Я надеюсь, что это имеет смысл для вас, так как я должен сделать некоторые серьезные предположения о природе этого клиента, сервера и канала.
Q. «Фальсифицируй, пока не сделаешь», оставил мне много грязного кода, который я позже потратил много времени на рефакторинг и очистку. Так все работает?
Если вы позволили своему "поддельному" коду испачкаться перед очисткой, то, возможно, вы слишком долго его фальсифицировали Тем не менее, я нахожу, что, хотя я в итоге убираю больше кода с помощью TDD, общий ритм ощущается намного лучше. Это приходит из практики.
Q. В конце сеанса мой клиент и сервер работают с 3 или 4 модульными тестами. Это заняло у меня около недели. Я думаю, что мог бы сделать это за день, если бы использовал модульные тесты после кода. Я не вижу усиления.
Я должен сказать, что если ваш клиент и сервер не очень, очень просты, вам нужно более 3 или 4 тестов каждый, чтобы тщательно их проверить. Я предполагаю, что ваши тесты проверяют (или, по крайней мере, выполняют) несколько различных поведений одновременно, и это может объяснить усилия, которые потребовались вам для их написания.
Кроме того, не измеряйте кривую обучения. Мой первый настоящий опыт работы с TDD состоял в том, что я переписал 3 месяца работы за 9, 14 часов. У меня было 125 тестов, которые заняли 12 минут. Я понятия не имел, что я делал, и он чувствовал себя медленно, но он чувствовал себя стабильно, и результаты были фантастическими. По сути, я переписал через 3 недели, что изначально потребовалось 3 месяца, чтобы ошибиться. Если бы я написал это сейчас, я мог бы сделать это через 3-5 дней. Различия? В моем наборе будет 500 тестов, которые будут выполняться в течение 1-2 секунд. Это пришло с практикой.