Запуск UnitTesting на Крупном проекте
Существует интерфейс python для парсера stanford
6 ответов
Во-первых, я второй "Работа Эффективно с Унаследованным кодом" рекомендация Jeffrey Frederick дал.
, Поскольку Вы заявили в вопросе, Вы не можете изменить свой код, потому что Вы в настоящее время не имеете модульных тестов в наличии для обнаружения регрессий, и Вы не можете добавить модульные тесты, потому что Ваша кодовая база не является тестируемой единицей. В этой ситуации можно создать тесты характеристики : от начала до конца автоматические тесты, которые помогли бы Вам обнаруживающий изменения во внешнем поведении Вашего программного обеспечения. После того как они существуют, можно начать медленно изменять код.
Однако подвергание Вашей ОГРОМНОЙ кодовой базы под тестом является огромным усилием, которым высоко рискуют, и Вы, вероятно, сожжете команду, делающую это, поскольку они должны будут произвести большие усилия с низким вознаграждением с точки зрения тестового покрытия. Подвергание всей кодовой базы под тестом является бесконечным усилием.
Вместо этого разрабатывают новую возможность из кодовой базы , так, чтобы она не препятствовала Вам. После того как новый код полностью тестируется, интегрируйте его в кодовой базе.
Также попытка создать модульные тесты каждый раз Вы решаете проблему в кодовой базе. Это будет твердо первые разы, но это станет легче, после того как у Вас будет некоторая среда поблочного тестирования готовой быть установкой.
Отсутствие опыта в письменной форме UnitTests/TDD
я думаю, что это старше значащее.
Стандартный совет состоит в том, чтобы начать писать модульные тесты на весь Ваш новый код сначала так, чтобы Вы изучили, как к модульному тесту перед попыткой к модульному тесту существующего кода. Я думаю, что это - хороший совет в теории, но трудно следовать на практике, так как самая новая работа является модификациями существующих систем.
я думаю, что Вы были бы хорошо обслужены при наличии доступа к "играющему тренеру", кто-то, кто мог работать над проектом с Вашей командой и преподавать навыки в процессе применения их.
И я думаю, что по закону обязан сказать Вам получать Michael Feather Работа Эффективно с Унаследованным кодом .
Там хорошие советы в книге Управляют им! Johanna Rothman.
я мог также recoment следующее:
- модульный тест Использования на недавно созданном фрагменте исходного кода
- Создает модульный тест на ошибки
- , Создают модульный тест на самую опасную часть приложения
- , Создают модульный тест на самую ценную часть приложения.
- , Если связь слишком высока, создают тест, которые являются большим количеством модуля или интеграционных тестов , но автоматизировали .
Один тест единого блока не поможет. Но необходимо запуститься. После, в то время как будет небольшое количество модульного теста на самой самой опасной части приложения и это поможет предотвращению ошибок в тех сегментах. Когда Вы доберетесь до этой точки, большинство разработчиков поймет, как полезные модульные тесты.
Вы не разберетесь в этой вещи самостоятельно. Существует большое необходимое убеждение. Таким образом, я хочу дать Вам этот поток, где большая информация и подсказки для хорошей аргументации дана: , Как Вы убеждаете других записать модульные тесты?
Только целая команда может создать такой большой размер модульных тестов.
Общее количество. Я должен был иметь дело с этим также. Лучшая вещь сделать, я думаю, состоит в том, чтобы склониться в большой степени на yucky инструментах, которые Вы, вероятно, не хотите использовать (как NUnitAsp) сначала, получать существующий код под тестами. Затем можно начать осуществлять рефакторинг, в то время как те инструменты мешают кодовой базе разваливаться из-под Вас.
Затем как Вы осуществляете рефакторинг, пишут тесты более логической единицы на новых, тестируемых частях, что Вы создаете и постепенно ликвидируете исходные тесты.
Удача с этим... Так как у Вас есть небольшой опыт с записью модульных тестов, я рекомендую сначала попытаться получить по крайней мере некоторый опыт. Иначе вероятно, что Вы будете abondon TDD/поблочное тестирование и возможно вводить новые ошибки в систему, которую Вы пробуете к модульному тесту. Лучший способ приобрести опыт состоит в том, чтобы найти, что кто-то испытал, кто может помочь Вам.