Интеграционные тесты и TDD

Question

У меня есть этот первый интеграционный тест для крестиков игры Tac Toe:

[TestClass] 
public class FirstIntegrationTest 
{ 
    [TestMethod, TestCategory("Integration Tests")] 
    public void Standard_TicTacToe_Game_PlayerO_Wins() 
    { 
     IPlayer playerO = new Player(); 
     IPlayer playerX = new Player(); 

     Game game = new Game(playerO, playerX); 
     game.Start(); 

     playerO.Play(new Point(0, 0)); 
     playerX.Play(new Point(2, 2)); 
     playerO.Play(new Point(1, 0)); 
     playerX.Play(new Point(1, 2)); 
     playerO.Play(new Point(2, 0)); 

     Assert.IsTrue(game.IsOver); 
     Assert.IsTrue(playerO.HasWon); 
     Assert.IsFalse(playerX.HasWon); 
    } 
} 

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

При проведении интеграционных тестов (и это интеграционный тест, я полагаю?), Какие тесты Unit-Tests я должен делать? Должен ли я просто сделать минимум, чтобы пройти тест интеграции? Если это так, мне нужно будет только сделать класс Game установить его первый IPlayerHasWon на true, а второй на false. Какой бы вопрос Unit-Testing вообще, если я буду управлять своим дизайном с помощью интеграционных тестов?

У меня есть идея, что в целом у вас нет много интеграционных тестов. Итак, следует ли мне управлять своим дизайном Интеграционными тестами или Unit-Tests?

Answer 1

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

Что вы имеете здесь приемочный тест высокого уровня.

возможные модульные тесты являются:

• обеспечивают игроки могут только по очереди поочередно
• обеспечивают игроки не могут одновременно отметить coordiate
• обеспечения победы в veritcal, диагональный и Horizonal распознаются (может проверить все 8 возможностей здесь)

Answer 2

Я бы не назвал это интеграционным тестом, для меня это больше похоже на Build Verification Test. Короткий и базовый тест, который вы запускаете после сборки для тестирования, если компоненты подходят друг к другу. Тест, который касается каждого модуля. Таким образом, вы проверяете, можете ли вы создавать игроков, создавать игру и играть в скрипт-игру.

Тест интеграции будет содержать больше тестов относительно интерфейсов между модулями (csci).

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

Итак, у вас будет много методов, охватываемых модульными тестами.

Пример для модульного тестирования конструктора класса Game:

IPlayer playerO = new Player(); 
    IPlayer player1 = new Player(); 
    IPlayer player2 = new AnotherImplOfIPlayer(); 

    Game game0 = new Game(player0, player1); // this should work 
    Game game1 = new Game(player0, player2); // this should work 
    Game game2 = new Game(null, null);   // exception thrown?  
    Game game3 = new Game(player0, player0); // exception thrown? 

---

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

A BVT подтверждает, что процесс сборки был верным и полным. Он проверяет, создало ли оно исполняемое приложение.

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

Answer 3

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

public void cannotPlaySameMovementTwice() { 
    playerO.Play(new Point(0, 0)); 
    playerX.Play(new Point(0, 0)); 
    // You should assert some exception result here 
} 

Answer 4

Проблема с ответом на ваш вопрос в том, что он субъективен, и мы не знаем ваше приложение, как вы.

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

Если вам будет легче писать и понимать интеграционные тесты или тесты конца, напишите их. Если вы думаете, что вам нужно будет поддерживать их меньше, тогда это путь.

Если вам будет легче протестировать каждый уголок и трещины, сфокусировавшись на модульных тестах, сделайте это. Если вы можете написать их в ремонте, то это будет хорошо работать.

По моему опыту, модульные тесты короче, и они могут копать глубже с меньшими усилиями. Вот почему я их предпочитаю. Я пишу меньше тестов интеграции (тесты, которые охватывают основные пути, и я обычно использую их как BVT), и даже меньше «сквозных» тестов (если у меня есть несколько пар клиентов-клиентов/серверов, полные процессы и т. Д., Чтобы проверить).

Answer 5

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

Этот конкретный тест не может пройти, пока вы не создали интерфейс, три класса и не менее четырех методов. Поэтому я бы не назвал это пробным вождением.

Answer 6

Разница между единичным тестом и интеграционным тестом очень субъективна.

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

Хотя я предпочитаю последнее определение, аргумент может быть сделан для каждого. И даже тогда, действительно ли это действительно вопрос в действительности? Это полезный тест, он быстрый, и он более стабилен, чем интеграционный тест. По этой причине я бы сгруппировал его с модульными тестами в локальном и CI-тестировании.

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

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