Лучший способ структурирования сборки модулей?

Question

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

Answer 1

Есть дерево возможных подходов к организации модульных тестов:

1. TestMethod в тестовом классе в классе тестирования. Самый популярный.
2. TestMethod в испытательном классе на испытательную арматуру. Позволяет минимизировать текст.
3. TestMethod в тестовом классе для каждой тестируемой системы (подсистема, модуль, пара классов).

Обычно существует потребность держать несколько автоматизированных тестовых сборок:

• Блок испытания в сборе - с блоком испытания чистой, что тестирование каждого блока с использованием издевается, тест свалки.
• Интеграция/сборка для тестирования потребителей - предназначенная для проверки интеграции системных блоков, проверка правильности функционирования критически важных потребителей.

Answer 2

Мне нравится один тестовый класс для конвенции класса из java. Это гарантирует, что вы всегда знаете, где найти тест, и тестовые блоки достаточно малы, чтобы на них работало много людей, без необходимости многого слияния, потому что все они находятся в одном файле.

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

Answer 3

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

Answer 4

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

unit-tests -> spec_for_job_status_page 

где spec_for_job_status_page папка, содержащая файл решения, файл csproj и связанные с ним классы.

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

namespace spec_for_job_status_page 
{ 
    [TestFixture] 
    public class when_the_job_status_page_is_loaded 
    { 
     [SetUp] 
     public void context() 
     { 
      //write set-up code here for your test 
     } 

     [Test] 
     public void should_show_the_job_number() 
     { 
      //write the assertion code here. Should be a single line 
     } 
    } 
}