Как сделать TDD с аппаратными средствами
Ваш файл .env еще не прочитан, когда создается экземпляр JwtModule. Так что либо прочитайте это ранее, например. в вашем main.ts до того, как будет создано приложение nest или лучше: создайте ConfigService и сделайте явную зависимость от вашей конфигурации:
JwtModule.registerAsync({
imports: [ConfigModule],
useFactory: async (configService: ConfigService) => ({
secretOrPrivateKey: configService.jwtSecret,
}),
inject: [ConfigService],
}),
См. этот ответ о том, как создать а ConfigService.
7 ответов
Разделите свой набор тестов на две части:
Первая часть запускает тесты против реальных аппаратных средств. Эта часть используется для создания макетов. Путем записи автоматических тестов для этого можно выполнить их снова, если у Вас есть какие-либо сомнения, работают ли Ваши макеты правильно.
Вторая часть выполняется против макетов. Эта часть работает автоматически.
Часть № 1 выполняется вручную после того, как Вы удостоверились, что аппаратные средства обеспечены электричеством правильно и т.д. Хорошая идея состоит в том, чтобы создать комплект тестов, которые работают против чего-то возвращенного фабрикой и запускают эти тесты дважды: Однажды с фабрикой, которая возвращает реальный "драйвер" и однажды против фабрики Ваших фиктивных объектов. Таким образом, можно быть уверены, что насмешки работают точно реальной вещью:
class YourTests extends TestCase {
public IDriver getDriver() { return new MockDriver (); }
public boolean shouldRun () { return true; }
public void testSomeMethod() throws Exception {
if (!shouldRun()) return; // Allows to disable all tests
assertEquals ("1", getDriver().someMethod());
}
}
В моем коде я обычно использую системное свойство (-Dmanual=yes) для переключения ручных тестов:
class HardwareTests extends YourTests {
public IDriver getDriver() { return new HardwareDriver (); }
public boolean shouldRun () { return "yes".equals (System.getProperty("manual")); }
}
Создайте тонкий слой для управления аппаратными средствами и используйте тестирование системы (ручной или автоматический) с полными аппаратными средствами, чтобы удостовериться, что слой управления работает как ожидалось. Затем создайте поддельную/ложную реализацию слоя управления, который ведет себя внешне как интерфейс к реальным аппаратным средствам, и используйте его при выполнении TDD для остальной части программы.
Несколько лет назад, я писал программное обеспечение для того, чтобы провести измерения с магнитометром сверхпроводящего квантового интерферометра. Аппаратные средства были большими, неперемещаемыми и дорогими (видео), таким образом, не было возможно всегда иметь доступ к аппаратным средствам. У нас была документация о протоколе связи с устройствами (через последовательные порты), но документация не была на 100% точна.
Что помогло нам, очень создавал программное обеспечение, которое слушает данные, прибывающие из одного последовательного порта, регистрирует его и перенаправляет его к другому последовательному порту. Затем мы смогли узнать, как старая программа (который мы заменяли) связалась с аппаратными средствами, и перепроектируйте протокол. Они были объединены в цепочку как это: Старая Программа <-> Виртуальный Петлевой Последовательный порт <-> Наш Регистратор данных <-> Реальный Последовательный порт <-> Аппаратные средства.
Тогда мы не использовали TDD. Мы действительно рассматривали запись эмулятора для аппаратных средств, так, чтобы мы могли протестировать программу в изоляции, но так как мы не знали точно, как аппаратные средства, как предполагалось, работали, было трудно записать точный эмулятор так в конце, мы не сделали этого. Если бы мы знали аппаратные средства лучше, то мы, возможно, создали эмулятор для их, и они сделали бы разработку программы намного легче. Тестирование с реальными аппаратными средствами было самым ценным, и задним числом мы должны были провести еще больше времени, тестируя с аппаратными средствами.
Если Вы пишете программное обеспечение для управления данными, прибывающими из специализированной части аппаратных средств, то Вы могли обоснованно создать заместителей для аппаратных средств для тестирования программного обеспечения.
Если аппаратный интерфейс является чем-то простым как последовательный порт, Вы могли бы легко использовать петлевой кабель, чтобы иметь Вашу программу, говорят с ложными аппаратными средствами. Я использовал этот подход несколько лет назад, чтобы запись программного обеспечения говорила с процессором кредита. Мое тестовое приложение было дано, чтобы думать, что то мое средство моделирования было модемом и программным процессором, функционирующим на сервере.
Если Вы пишете драйверы устройств PCI или эквивалентное программное обеспечение уровня, то Вы, вероятно, не можете создать заместителя программного обеспечения.
Единственный хороший способ применить TDD к таким проблемам состоит в том, если Вы можете имитировать i/o аппаратных средств с другой программой. Например, я работаю с обработкой кредитной карты для автозаправочных станций. На моем текущем проекте у нас есть средство моделирования, которое является электроникой насоса, сцепленной с некоторыми переключателями, таким образом, что эксплуатация насоса (дескриптор лифта, сожмите триггер, топливный поток) может быть моделирован. Довольно возможно, что нам можно было создать средство моделирования, которое было управляемо программным обеспечением.
Поочередно, в зависимости от устройства, Вы смогли использовать стандартное тестовое оборудование (генераторы сигнала, и т.д.) для питания его 'известные исходные данные'.
Обратите внимание, что это имеет проблему, что Вы тестируете и аппаратные средства и драйверы устройств вместе. К сожалению, это - действительно единственный хороший выбор, который Вы имеете на данном этапе - Любые моделируемые аппаратные средства, вероятно, будут достаточно отличаться от реального оборудования, с которым будет бесполезным протестировать.
Вероятно, не хорошая идея включать тесты получают доступ к аппаратным средствам в Вашем наборе тестов. Одна из проблем с этим подходом - то, что тесты только смогут работать на машине, которая подключена к этой специальной части аппаратных средств, которые мешают запускать тесты, говорят как часть (ночного) автоматического процесса сборки.
Одно решение могло состоять в том, чтобы записать некоторые программные модули, которые ведут себя как недостающие аппаратные модули, по крайней мере, с интерфейсной точки зрения. При выполнении набора тестов получите доступ к этим программным модулям вместо реальных аппаратных средств.
Мне также нравится идея разделить набор тестов на две части:
- тот, который получает доступ к реальным аппаратным средствам, которые Вы выполняете вручную
- тот, который получает доступ к программным модулям, который работает как часть автоматического тестирования
По моему опыту, тесты, которые включают реальные аппаратные средства почти всегда, требуют некоторой суммы ручного взаимодействия (например, включите что-то и видеть, обнаруживается ли это правильно), который делает его очень трудно для автоматизации. Преимущества часто просто не стоят проблемы.
Если у Вас есть средство моделирования, Вы могли бы записать тесты против средства моделирования и запустить эти тесты против аппаратных средств.
Трудно ответить на вопросы с такой небольшой деталью :-)
Когда я работал над абонентскими установками, у нас был инструмент, который генерирует насмешки от любого API C с комментариями doxygen.
Мы были бы затем главный насмешки с тем, что мы хотели, чтобы аппаратные средства возвратили чтобы модульному тесту наши компоненты.
Таким образом в примере выше Вы установили результат FrameGrabber_API_IsDeviceAttached, чтобы быть ложью, и когда Ваш код вызывает ту функцию, это возвращает false, и можно протестировать его.
То, как легкий это должно будет протестировать, зависит от того, как что в настоящее время структурируется Ваш код.
Инструмент мы раньше генерировали насмешки, был в доме, таким образом, я не могу помочь Вам с этим. Но существует некоторый обнадеживающий хит Google: (правовая оговорка - я использовал любой из них, но надо надеяться они могут помочь Вам),
- http://code.google.com/p/googlemock/
- http://www.opensourcetesting.org/unit_c.php
- http://spin.atomicobject.com/2006/12/29/cmock-ruby-based-mock-tools-for-c
Просто проверка - у Вас есть что-то как прямые вызовы ioctl в Вашем коде или чем-то? Это всегда трудно копировать. У нас был слой обертки ОС, что мы могли легко записать насмешки для того, таким образом, это было довольно легко для нас.