Использование TDD для создания отчета

Question

В настоящее время я пытаюсь использовать PHPUnit для изучения Test Driven Development (TDD), и у меня есть вопрос о написании отчетов с использованием TDD.

Прежде всего: я понимаю основной процесс TDD:

Но у меня такой вопрос: как вы используете TDD для написания отчета?

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

Как вы пишете тесты для метода, результаты которого вы не знаете? Результат метода, который коррелирует эти данные, изменится в зависимости от диапазона дат и других ограничивающих критериев, которые пользователь может предоставить при запуске отчета? Как вы работаете в рамках TDD в такой ситуации, используя такую ​​среду, как PHPUnit?

Answer 1

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

Для сравнения, если вы тестировали функцию, которая ожидала положительное целое число между1 и 100, вы бы написали 100 тестов для проверки каждого целого числа?Нет, вы бы проверили что-то в пределах диапазона, затем что-то на границах и вокруг них (например, -1, 0, 1, 50, 99, 100 и 101).Вы не тестируете, например, 55, потому что этот тест будет идти по тому же пути кода, что и 50.

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

Answer 2

Очень сложно, и часто неразумно, тестировать непосредственно на вашем производственном сервере, поэтому лучше всего подделать его.

Сначала вы создаете stub, специальный объект, который стоит вдля базы данных, которая позволяет вашим модульным тестам притворяться, что какое-то значение пришло из БД, когда оно действительно пришло от вас.Если потребуется, у вас есть что-то, что способно генерировать что-то, что вам неизвестно, но все еще доступно для тестов.

Как только все будет работать, вы можете иметь набор данных в самой БДнекоторая схема тестирования - в основном, вы подключаетесь, но с другими параметрами, так что пока он думает, что смотрит на PRODUCTION.CAR_TABLE, он действительно смотрит на TESTING.CAR_TABLE.Возможно, вы даже захотите каждый раз иметь тестовую таблицу удаления / создания (хотя это может быть немного, но это приведет к более надежным тестам).

Answer 3

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

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

А если вам нужно взаимодействовать с объектами, вы тоже можете издеваться над ними .

Хорошо, что вы можете протестировать все порочные данные крайнего случая, о которых вы думаете, когда пишете код (эй, а что если данные содержат неэкранированные кавычки?).