Предотвращение кода Rot 101: модульное тестирование

Один мудрый программист однажды сказал: «Когда я фиксирую свой код, только Бог и я знаем, что он делает. Через некоторое время только Бог знает ». Это базовое определение гнили кода, которое применимо почти ко всему коду, который мы пишем.

Конечно, код все равно будет делать то же, что и когда вы его зарегистрировали или когда отправили в производство, но, поскольку он работает, он становится чем-то волшебным: проверенная правда, и вы не трогаете проверенные истины. Со временем код превращается в чудовище, которого никто не осмеливается трогать, унаследованную часть кодовой базы. Он был разработан «давным-давно», он функционировал точно так же с момента своего выпуска, и никто не понимает его полностью. Если что-то нужно изменить, вы взломаете это; Вы изменяете вход или выход, но оставляете черный ящик нетронутым.

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

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

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

Основы модульного тестирования

В принципе, модульное тестирование — это небольшой фрагмент кода, который выполняет 3 вещи:

• Assemble — настраивает среду, аналогичную той, в которой код будет выполняться во время производства, но без зависимости от других компонентов в вашем коде
• Act — выполняет часть кода, которая будет доказана
• Утверждает — проверяет, что результат казни соответствует ожидаемому с учетом обстоятельств

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

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

На связанной ноте, не стесняйтесь игнорировать номера покрытия кода. Это бесполезные показатели. Единственное, что имеет значение, — есть ли у действующих компонентов или узлов доказательства. У вас может быть колоссальное покрытие кода 95%, но если эти 5% составляют основную бизнес-логику, у вас все еще есть (будущие) черные ящики, ожидающие начала гниения.

собирать

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

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

<?php
...
    // ** ORIGINAL METHOD **/
    public function getCustomerFirstNames(DBLayer $db) {
        $dbvalues = $db->getQueryResults("SELECT firstname FROM customers");
        $firstnames = array();
        foreach($dbvalues as $firstname) {
            $firstnames[] = ucfirst($firstname);
        }
        return $firstnames;
    }
...

 <?php
//** Mock for DB layer **/
class DBLayer
{
    public function getQueryResults($sql) {
        return array("John", "tim", "bob", "Martin");
    }
}

 <?php
...
    //**PHPUnit testcase **/
    public function setUp() {
        //mock file included instead of real file
        $this->db = new DBLayer();
    }
 
    public function testGetcustomerfirstnamesWillReturnFirstnamesModifiedByUcfirst() {
        // assemble (together with the runonce setUp() method)
        $obj = new OriginalClass();
        $expected = array("John", "Tim", "Bob", "Martin");
        // act
        $results = $obj->getCustomerFirstNames($this->db);
        // assert
        $this->assertEquals($expected, $results, "GetCustomerFirstNames did not ucfirst() the list of names correctly");
    }
...

При таком подходе были достигнуты две вещи:

• Тестовый компонент не зависит от других компонентов.
• Собранная среда, в которой мы запускаем тест, предсказуема; он будет вести себя одинаково при каждом запуске теста

Действовать и утверждать

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

Утверждение просто гласит: «при известном вводе x, обработанном известной функцией f, выводом является f (x)». Разработчик, который написал функцию f и сопутствующий модульный тест, написал эту функцию, чтобы решить конкретную проблему под рукой. Тест устраняет необходимость знать или даже понимать проблему, или почему она была решена определенным образом. Функциональность кода была принята (и, надеюсь, постоянно принимается приемочными тестами), так что пока проходит модульное тестирование; код подтвержден