Тестирование процедурного кода - PullRequest
4 голосов
/ 13 декабря 2011

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

<?php

// gather some data
// do something with that data
// instantiate a bunch of globals

// output a bunch of stuff to the browser

include_once "file.php";

// output some more stuff
include_once "file2.php";

// ad nauseum

затем в file.php

<?php

// do something with the globals from above
// gather some more data
// do something with this newfound data
// output more stuff to the browser

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

Ответы [ 6 ]

4 голосов
/ 13 декабря 2011

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

Вы можете попытаться найти Соединительные швы и другие подобные уловки, но, скорее всего, вас ждет мир боли, если вы не начнете менять парадигму. Если вы не можете разбить свой процедурный PHP на достаточно крошечные файлы с установленными точками ввода и вывода, которые вы можете протестировать каждый в отдельности. Но это определенно потребует создания методов и устранения как можно большего числа ГЛОБАЛОВ.

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

1 голос
/ 14 декабря 2011

Товарищ кодеры, Хотя я согласен с использованием Selenium и тому подобного ... Я хотел бы указать на это: Мы говорим о TDD. По моему скромному опыту, TDD - это то, что вы подхватываете, как грипп. Сначала нужно понять объектно-ориентированное программирование, затем следует изучить модульное тестирование.

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

На этом этапе вы начнете TDD.

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

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

Короче говоря, в зависимости от бизнес-модели вашей организации, вам может быть или не быть предоставлено адекватное планирование. Но вы должны нажать на.

Не бойтесь, потому что благодаря настойчивости однажды вы сможете объяснить эту самую вещь следующему молодому парню или даме, пытающейся вступить в TDD.

Удачного кодирования.

0 голосов
/ 28 января 2013

Получение проверяемого процедурного кода - кошмар, но возможен поэтапный подход. Учтите это:

// bar.php
$priceWithoutTax = 10;
$priceWithTax = 10 * $annoyingGlobalVarWithTaxRateInIt;
echo $priceWithTax;

Вы должны прицелиться в первую очередь, чтобы достичь:

//bar.php
echo Foo::getPriceWithTax($annoyingGlobalVarWithTaxRateInIt);

//Foo.php
class Foo {
    public static function getPriceWithTax($annoyingGlobalVarWithTaxRateInIt) {
        $priceWithoutTax = 10;
        $priceWithTax = 10 * $annoyingGlobalVarWithTaxRateInIt;
        return $priceWithTax;
    }
}

//FooTest.php
public function testGetPriceWithTax() {
    $expectedResult = 12;
    $taxRate = 1.2;
    $this->assertEquals($expectedResult, Foo::getPriceWithTax($taxRate));
}

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

Цель этого, предполагая, что ваш код иногда делает что-то более сложное, чем умножение на 10, состоит в том, чтобы обеспечить безопасный рефакторинг. Теперь вы можете вносить изменения в реализацию расчета (что для более сложной бизнес-логики, чем эта, вероятно, должно включать правильную ориентацию объекта ;-)), будучи уверенным в том, что ваши тесты сообщат вам, если Вы что-нибудь сломали.

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

Удачи.

0 голосов
/ 13 декабря 2011

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

0 голосов
/ 13 декабря 2011

TDD означает, что тесты на первом месте. Вам не нужно тестировать существующий код, вы должны тестировать новый. В конце концов, это модульное тестирование - он тестирует кусок кода, а не всю страницу. Чтобы убедиться, что все работает так же, как и до рефакторинга, вам нужно написать тесты другого типа - функциональные. В основном эмулируйте HTTP-запросы и проверяйте ответы. Такие тесты могут быть построены, например, с помощью selenium, и некоторые PHP-фреймворки, такие как symfony, предоставляют для этого собственную инфраструктуру тестирования на стороне сервера.

0 голосов
/ 13 декабря 2011

Метод извлечения и Класс извлечения Рефакторинг.Комментарии являются подсказками, указывающими, как назвать эти методы / классы.

Для тестовых структур см .: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#PHP

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