Запись стандартов для поблочного тестирования

Необходимо, вероятно, смотреть на серию "Pragmatic Unit Testing". Это - версия C#, но существует другой для Java.

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

Обновление: Я не соглашаюсь с Мистером Картофельная Голова о только одном, утверждают на Модульный тест. Это звучит довольно прекрасным в теории, но на практике это приводит или к загрузкам главным образом избыточных тестов или к людям, делающим тонны работы в установке и разрушении, которое самом должно быть протестировано.

1. Попытайтесь использовать как можно меньше операторов контроля на метод тестирования. Это удостоверяется, что цель теста четко определена.
2. Я знаю, что это будет спорно, но не тестирует компилятор - время, проведенное, тестируя Бобовые средства доступа Java и мутаторы, лучше проведено, пишущий другие тесты.
3. Попытайтесь, если это возможно, использовать TDD вместо того, чтобы писать Ваши тесты после Вашего кода.

Я следую за стилем BDD TDD. См.: http://blog.daveastels.com/files/BDD_Intro.pdf http://dannorth.net/introducing-bdd http://behaviour-driven.org/Introduction

Короче говоря это означает это

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

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

• Существует не вызван 1:1 отношение между производственными классами и классами спецификации (и генерация метода тестирования для каждого производственного метода была бы безумна). Вместо этого существует 1:1 отношение между поведением системы и спецификациями.

Некоторое время назад я записал учебное руководство TDD (где Вы начинаете писать игру Тетриса с помощью обеспеченных тестов), который показывает этот стиль записи тестов как спецификации. Можно загрузить его с http://www.orfjackal.net/tdd-tutorial/tdd-tutorial_2008-09-04.zip инструкции о том, как сделать, TDD/BDD все еще отсутствует в том учебном руководстве, но пример кода готов, таким образом, Вы видите, как тесты организованы и пишут код, который передает их.

Вы заметите, что в этом учебном руководстве производственные классы называют, такие как Совет, Блок, Piece и Tetrominoe, которые центрируются вокруг понятия игры Тетриса. Но тестовые классы центрируются вокруг поведения игры Тетриса: FallingBlocksTest, RotatingPiecesOfBlocksTest, RotatingTetrominoesTest, FallingPiecesTest, MovingAFallingPieceTest, RotatingAFallingPieceTest и т.д.

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

public class MyService {
    public String method1(){
        return "";
    }

    public void method2(){

    }

    public void method3HasAlongName(){

    }
}

Когда я нажимаю ctrl-shift-T в intellij ИДЕЕ, я получаю этот тестовый класс после ответа на 1 диалоговое окно:

public class MyServiceTest {
    @Test
    public void testMethod1() {
        // Add your code here
    }

    @Test
    public void testMethod2() {
        // Add your code here
    }

    @Test
    public void testMethod3HasAlongName() {
        // Add your code here
    }
}

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

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

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

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

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

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

Я также защищаю стиль Arrange-Act-Assert (AAA) тестирования, поскольку можно затем генерировать довольно полезную документацию от тестов. Это также вынуждает Вас рассмотреть, какое поведение Вы ожидаете из-за стиля именования.

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

TEST( TestThatVariableFooDoesNotOverflowWhenCalledRecursively )
{
/* do test */
}  

Я использую C++, но соглашение о присвоении имен может использоваться где угодно.

Удостоверьтесь, что включали то, что не является модульными тестами. См.: Что не протестировать когда дело доходит до Поблочного тестирования?

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

Проверьте это на большее количество информации о нем: Как я могу улучшить свои тесты junit... особенно второе обновление.

При использовании инструментов от семейства Junit (OCunit, SHunit...), названия тестов уже следуют некоторым правилам.

Для моих тестов я использую пользовательские теги doxygen для сбора их документации на определенной странице.