Как бы вы применили модульное тестирование в этой ситуации?

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

Оба класса тестов полезны. Интеграционные тесты, такие как ваши, проверяют систему от начала до конца, чтобы убедиться, что все работает вместе. Но они медленные и часто имеют внешние зависимости (например, кард-ридер). Юнит-тесты меньше по размеру, быстрее и очень целенаправленны, но трудно увидеть лес за деревьями, если все, что у вас есть, — это модульные тесты.

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

Теперь, как вы проводите модульное тестирование в вашей конкретной ситуации, когда методы зависят от других методов? Неясно, сколько кода вы контролируете, а сколько находится в библиотеках, но в своем коде научитесь использовать внедрение зависимостей (DI) как можно чаще.

Предположим, ваш метод чтения выглядит примерно так (в псевдокоде)

boolean WriteToCard(String data){
   // do something to data here
   return ICE_API.WriteToCard(ICE_API.SOME_FLAG, data)
}

Ну, вы должны быть в состоянии изменить это на что-то вроде:

    ICE_API api = null

    ICE_API setApi(ICE_API api) {
         this.api = api
    }

    ICE_API getApi() {
      if (api == null) {
        api = new ICE_API()
      }
    }

    boolean WriteToCard(String data){
        // do something to data here    
        return getApi().WriteToCard(ICE_API.SOME_FLAG, data)
    }

Затем в вашем тесте для WriteToCard в настройках вы должны сделать

void setup()
  _mockAPI = new Mock(ICE_API)
  reader.setApi(_mockAPI)

void testWriteToCard()
  reader.writeToCard("12345")
   // assert _mockAPI.writeToCard was called with expected data and flags.

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

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

Для модульного тестирования я предпочитаю использовать сайт Миско Хевери. Надеюсь, поможет!

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

Один из способов исправить это — создать процедуру инициализации теста (с использованием атрибута [SetUp] в вашем классе [TestFixture]), которая приводит систему в известное состояние перед выполнением одного теста.

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

Затем вы можете реализовать тестирование фактического реального API либо в модульном тесте, либо во что-то еще, что требует минимального человеческого взаимодействия... в основном вы будете инкапсулировать человека в свой процесс тестирования;)