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

Как говорится в названии. Какие способы вы используете для проверки своего собственного кода, чтобы это не было скучной задачей? Вы используете какой-либо инструмент? Для моих проектов я использую электронную таблицу для перечисления всех возможных подпрограмм, то есть из основного CRUD, а также всех странных подпрограмм. Я делаю около 10 процедур.

Я получаю около 2-3 ошибок, а иногда и крупных, делая это. И если я этого не делаю, клиент сообщает о другой ошибке.

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

Edit:

Я забыл упомянуть, что я особенно работаю над веб-приложениями, а мой язык - это PHP и Cakephp framework.

Ответ 1

Быстрые тесты. (Более) немедленная обратная связь помогает ускорить короткие итерации. Это может заставить вас пристраститься к началу следующего тестового прогона.

Ответ 2

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

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

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

Итак, оставьте этот лист excel и пошаговый отладчик и присоединитесь к забаве:-)

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

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

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

Ответ 3

Я думал так же, как и ты. Когда я только начинал программировать, нам приходилось разрабатывать, что будет выводить на бумаге, а затем делать визуальные сравнения фактического и ожидаемого результата. Поговорите о утомительном. Пару лет назад я обнаружил Test Driven Development и xUnit, и теперь мне нравятся тесты.

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

Напишите модульные тесты с автоматическим, PhpUnit или Simpletest, поскольку вы используете PHP или любую другую модульную систему тестирования, доступную для вашего язык выбора. Следуя Test-Driven Development (TDD), вы создадите тестовый набор вместе с вашим кодом. У вас не будет впечатления, что вы что-то тестируете. На самом деле.

"* немного проверьте, немного код *.

Ответ 9

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

В основном вы пишете кучу файлов с расширением .t в каталоге t/ вашего проекта, а затем запустите prove.

Файлы в t/ в основном выглядят следующим образом:

#!/usr/bin/perl
use strict;
use warnings;

use Test::More tests => 8;

use Date::ICal;

$ical = Date::ICal->new( year => 1964, month => 10, day => 16, 
                         hour => 16, min => 12, sec => 47, 
                         tz => '0530' );

ok( defined $ical,            'new() returned something' );
ok( $ical->isa('Date::ICal'), "  and it the right class" );
is( $ical->sec,     47,       '  sec()'   );
is( $ical->min,     12,       '  min()'   );    
is( $ical->hour,    16,       '  hour()'  );
is( $ical->day,     17,       '  day()'   );
is( $ical->month,   10,       '  month()' );
is( $ical->year,    1964,     '  year()'  );

Для получения дополнительной информации вы можете прочитать tutorial.

Существует много языков, которые имеют модули, предназначенные для работы с TAP, посмотрите здесь для получения дополнительной информации.

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

Ответ 14

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

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

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

Ответ 15

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

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