Как к модульному тесту?
В основном у меня есть два основных вопроса:
- Что точно должно Вы модульный тест?
- Как дела это?
Проблема, у меня есть несколько приложений, которые полагаются в соединении с базой данных и/или являются коммуникационными приложениями, которые означают, что большинство тестовых сценариев является интеграционными тестами (или таким образом, я думаю).
Большинство классов довольно просто собой, но те, которые реализуют протокол связи, которые являются теми, которые были бы полезны для автоматизации тестирования, может казаться, соответствуют хорошо модели "модульного теста".
Другой пример. Я разработал, я передаю структуру по каналу с многопоточной поддержкой шаблона потребителя/производителя. Когда поток читает канал и находит, что освобождает его блоки, пока писатель не пишет в канал. Я должен использовать модульные тесты для тестирования того класса?
Как Вы решаете что к модульному тесту?
Править: Я означаю писать модульные тесты на автоматизированное поблочное тестирование.
4 ответа
Вы проводите Unit-тесты единиц вашего кода. Главный вопрос - что именно составляет единицу?
В объектно-ориентированной среде единица - это класс. Класс, потому что поведение объекта зависит от состояния объекта, поэтому тестирование метода в изоляции не даст наиболее полных результатов.
Сначала необходимо определить инварианты класса. То есть то, что всегда будет верно для всех экземпляров класса. Например, в классе Fraction инвариантом может быть знаменатель != 0.
Затем нужно определить контракты каждого метода, то есть предварительные и последующие условия методов.
Затем вы пишете тесты для каждого условия, которое может возникнуть. Таким образом, для одного класса у вас может быть множество тестовых методов для проверки различных условий, с которыми может столкнуться каждый метод. При каждом тестировании вы убеждаетесь, что инварианты класса выполняются и контракт метода никогда не нарушается.
В некоторых случаях, как в приведенном вами примере, может потребоваться создать другие объекты в окружении, чтобы протестировать условия вашего класса. В таких случаях вы можете использовать объекты-макеты.
Вы должны абстрагироваться от инфраструктурных проблем (т.е. кода, который получает данные из базы данных, кода, который выполняет ввод-вывод файлов и т.д.), чтобы вы могли использовать заглушки/моки этих частей для модульного тестирования вашего приложения. А затем вы сможете написать целевые/специфические тесты против кода вашей инфраструктуры, чтобы проверить это.
Вы обнаружите, что создаете больше интерфейсов (для создания видимости внутри вашего приложения) и должны использовать лучшие принципы ОО (т.е. SOLID), чтобы разработать приложение, которое лучше поддается тестированию.
Год назад я был в той же лодке, что и вы. И единственная книга, которая действительно помогла мне в этом (наряду с практическими занятиями) - The Art of Unit Testing by Roy Osherove
Модульное тестирование - это тестирование всего модуля, работающего так же, как и до изменения, с внесенными улучшениями в изменении .. Если вы вносите изменения в окно модуля, вы тестируете модуль. Это по сравнению с системным тестом, который тестирует каждый модуль. Если ваше изменение затронуло многие модули (не знаете, как настроена ваша система), то оно должно пройти системный тест.
Модульные тесты тестовых единиц (то есть метода или функции) изолированно , в выделенная, контролируемая среда. Каждый модульный тест создается в собственной среде путем создания экземпляров только тех классов, которые необходимы для выполнения одного теста, переводя их в известное состояние, затем он вызывает метод, который нужно протестировать, и проверяет результат. Эта проверка выполняется утверждениями о поведении метода (в отличие от его реализации).
Выполнение проверки поведения, а не реализации важно, поскольку это позволяет изменять реализацию без нарушения модульных тестов и, следовательно, использовать модульные тесты как страховочную сетку для модификации.
Все языки имеют [по крайней мере] одну среду модульного тестирования , роль которой заключается в выполнении модульных тестов. Есть два способа написать модульные тесты: test-first или test-last.
Сначала тестирование также называется Разработка через тестирование . В основном это занимает три шага:
- написать неудачный тест
- написать достаточно кода, чтобы он прошел
- рефакторинг кода, чтобы очистить его (удалить дублирование ...)
Сторонники TDD утверждают, что это приводит к тестируемому коду, хотя может быть сложно писать модульные тесты постфактум, особенно когда методы выполняют несколько функций.Рекомендуется придерживаться принципа единой ответственности.
Что касается примера структуры канала и протокола связи, в некоторых рекомендациях говорится, что тест не является модульным, если :
- Он обращается к базе данных
- Он обменивается данными через сеть
- Он касается файловой системы
- ...
Когда поток читает канал и находит его пустым, он блокируется, пока писатель не запишет в канал. Следует ли мне использовать модульные тесты для тестирования этого класса?
Я бы тестировал класс, но не метод блокирующего чтения, поскольку я предполагаю, что он построен на основе блокирующего вызова read () Операционной системы.