Как сделать тестирование не скучным?

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

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

1. программы это работает

2. набор тестов, который остается и проверить его каждый строит

поэтому оставьте этот лист excel и шаг за шагом отладчик и присоединяйтесь к веселью: -)

конечно, есть еще и это, где тестовые фреймворки (junit, testNG, Dunit, NUnit ...) пригодится, они уберут небольшие боли и оставят только кодирующую часть теста..

счастливое кодирование и расширение.. счастливое тестирование :-)

несколько ссылок, которые вы можете найти полезными, я не эксперт PHP, далеко от этого, но это, казалось, соответствовало цели.

• http://www.simpletest.org/
• http://www.phpunit.de/
• http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/

раньше я думал так же, как и ты. Когда я только приступил к программированию, мы должны были определить, какой результат будет на бумаге, а затем провести визуальное сравнение фактического и ожидаемого результатов. Поговорим о нудном. Пару лет назад я обнаружил разработку с тестовым приводом и xUnit, и теперь я люблю тесты.

в основном, в TDD у вас есть структура, позволяющая вам писать тесты и запускать их очень легко. Итак, написание тестов становится просто написанием кода. Процесс есть:

1. просто напишите достаточно, чтобы позволить вам написать тест. Например, вы добавляете метод в класс, поэтому вы просто пишете метод sig и любой оператор return, необходимый для его компиляции.
2. затем вы пишете свой первый тест и запускаете фреймворк, чтобы увидеть, что он терпит неудачу.
3. затем вы добавляете код в / рефакторинг вашего метода, чтобы пройти тест.
4. затем вы добавляете следующий тест и видите, что он терпит неудачу.
5. повторяйте 3 и 4, пока не сможете думать больше никаких тестов.
6. вы закончили.

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

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

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

xUnit-это общее имя для множества фреймворков, поддерживающих разные языки: JUnit для Java, NUnit для .NET и т. д. Вероятно, уже есть один для любого языка, который вы используете. Вы можете даже написать свой собственный фреймворк. Прочтите эту книгу-она превосходна.

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

для поиска ошибок в существующем коде тест, который воспроизводит ошибку, упрощает ее тестирование.

Это не скучно, потому что в обоих случаях тесты имеют высокую вероятность провала.

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

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

вы, вероятно, имеете в виду утомительно, а не скучно. Если так, то в этой статье может поможет

" нет тестирования, нет скучно."

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

один из советов, которые я даю своей команде, заключается в том, что в отношении новых функций 90% логики должно выходить из контекста приложения.

функции, которые могут работать вне контекста приложения, всегда легко протестировать.

Если вы используете .net, вы можете исследовать Нанит.

вы также можете посмотреть Pex. Кажется, это потрясающая тестовая структура.

однако ваш вопрос немного общий, потому что существует много типов тестирования.

получайте удовольствие от тестирования :).

Я пытаюсь сначала написать свои тесты и попытаться создать класс вокруг него. Поэтому я действительно сосредоточен на тесте. Я использую JUnit и т. д.

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

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

напишите некоторые модульные тесты / автоматические тесты, которые будут запускаться автоматически, например, после завершения новой сборки.

Используйте инкапсуляцию и попробуйте протестировать только интерфейсы.

Напишите несколько небольших инструментов, которые помогут вам протестировать ваши модули / классы.

сделать простой в использовании, набор тестов легко сделать для программ Perl. Существует стандартный способ тестирования в Perl с помощью Проверить Любой Протокол.

в основном вы пишете кучу файлов с

сначала используйте тестовый первый подход \ парный тест программирования.

Если вы пишете их после того, как вы написали свой собственный код, то ваша цель-найти ошибки в вашей работе = sad target.

и наоборот, если вы пишете свои тесты перед кодом, то ваша цель-написать безупречное программное обеспечение = happy target.

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

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