Модульное тестирование - это то, что вы делаете, когда пишете код.Это тестирование проверяет ваше представление о том, как все должно работать (на уровне класса / метода / алгоритма), и поддерживает вас при разработке, поскольку вы можете проходить тесты до и после внесения изменений, чтобы увидеть, что все работает.по-прежнему в соответствии с тестами у вас на месте.Посмотрите на это как на то, что поможет программисту , когда он / она работает.Кроме того, тесты также позволят увидеть, как что-то должно работать для любого, кто смотрит на код. TDD (разработка через тестирование) не меняет эту концепцию , а скорее подчеркивает, что единый код должен сначала подумать, как он должен работать и чего ожидать.
Если есть проблема сне видя собственных проблем, можно попробовать парное программирование, обзоры кода или другие способы взглянуть на вещи с большим количеством глаз и умов.Тем не менее я твердо верю, что модульное тестирование является инструментом для программиста , а не кем-то другим.
Переход к другим типам тестирования, таким как интеграционное тестирование , функциональное тестирование или даже (система) тестирование производительности , было бы хорошо, если бы другие люди делали это.Особенно, если вы хотите автоматизировать это тестирование, требуется, чтобы вы знали, как что-то делать, а также, возможно, имели более высокий уровень бизнес-знаний о том, что тестировать и как.
Ответ на ваш вопрос также зависит от культуры иОднако, как работает ваша организация, я считаю, что во всех случаях вы хотите проводить модульное тестирование как часть разработки кода.Если это приводит к проблемам, может быть что-то еще, что не работает в организации, или что-то, на что нужно обратить внимание.
Обновление
Вот несколько вещейЯ видел в организациях, которые влияют на практику модульного тестирования:
- некоторые люди могут не захотеть писать модульные тесты;
- некоторые люди могут не знать, как писать хорошие модульные тесты, которыеможет подорвать преимущества этого, и это может быть использовано как «доказательство» того, что модульное тестирование является плохим;
- организация может не объединять людей для совместной работы, а выполнять разные обязанности, такие как код программистов, тестирование тестерови т. д., что может привести к принудительному юнит-тестированию;
- некоторые люди могут быть наняты для написания юнит-тестов, поэтому, если эта роль не изменилась, это противоречит написанию юнит-тестов при кодировании;
- тамэто может быть очень маленькая организация, которая может означать, что каждый делает всего понемногу;
- организация в целомне признает ли выгода от модульного тестирования, а скорее просто-напросто код, как можно быстрее и справиться с проблемами позже,
- кто возглавляет усилия по проведению модульного тестирования?Это один человек?Разработчики?Руководство?
- Может ли организация самостоятельно решать, кто выполняет юнит-тестирование?
Если существует соглашение о проведении юнит-тестирования, могут возникнуть проблемы, с которыми нужно разобраться, чтобыпривести организацию в состояние, когда все просто работает естественно.Если у вас есть человек с хорошими практиками юнит-тестирования и опытом , пусть они заставят привести остальных членов команды , чтобы увидеть магию юнит-тестирования .
Лично я считаю , что если люди видят преимущества модульного тестирования, могут написать хорошие модульные тесты, автоматизировать их с помощью сборок, и если команда может самостоятельно решить, как организовать, как получитьнаписанные модульные тесты все естественно встанут на свои места , так что разработчики пишут модульные тесты при разработке кода, любой может в любой момент добавить дополнительные модульные тесты для любого кода, на который они смотрят.Если имеется тестеров , они сосредоточатся на других типах тестирования, таких как функциональное тестирование или предварительное тестирование.