Запуск UnitTesting в LARGE проекте

Ответ 1

Во-первых, я повторю рекомендацию Джеффри Фредерика "Эффективно работая с устаревшим кодом".

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

Тем не менее, сдача вашей тестовой базы HUGE - это огромные усилия, очень рискованные, и вы, вероятно, сожжете команду, которая сделает это, так как им придется прилагать сильные усилия с низкой премией в плане охвата тестированием. Ввод всей тестируемой базы кода - это бесконечные усилия.

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

Также старайтесь создавать модульные тесты каждый раз, когда вы исправляете проблему в базе кода. Это будет сложно в первый раз, но это станет легче, если у вас будет готовая установка для тестирования компонентов.

Ответ 2

Отсутствие опыта в письменной форме UnitTests/TDD

Я думаю, что это самое важное.

Стандартная рекомендация - сначала начать писать единичные тесты для всего вашего нового кода, чтобы вы узнали, как unit test, прежде чем пытаться выполнить unit test существующий код. Я думаю, что это хороший совет в теории, но трудно следовать на практике, поскольку большинство новых работ - это модификации существующих систем.

Я думаю, вам будет хорошо обеспечен доступ к "тренеру игроков", кто-то, кто мог бы работать над проектом с вашей командой и преподавать навыки в процессе их применения.

И я думаю, что я юридически обязан сказать вам, чтобы Майкл Перо Эффективно работал с устаревшим кодом.

Ответ 3

Есть хорошие советы в книге Управляйте им! от Johanna Rothman.

Я мог бы также рекомендовать следующее:

• Используйте unit test для вновь созданного исходного кода
• Создайте unit test для ошибок
• Создайте unit test для самой опасной части приложения
• Создайте unit test для наиболее важной части приложения.
• Если соединение слишком велико, создайте тест, в котором больше тестов модулей или интеграции , но автоматизировано.

Один единственный unit test не поможет. Но это нужно начинать. После того, как будет самая сложная часть приложения unit test, и это поможет предотвратить ошибки в этих сегментах. Когда вы доберетесь до этого момента, большинство разработчиков поймут, насколько полезны единичные тесты.

Ответ 4

Вы не получите эту вещь самостоятельно. Там нужно много убеждений. Поэтому я хочу дать вам эту тему, где дается много информации и подсказок для хорошей аргументации: Как вы убеждаете других писать модульные тесты?

Только вся команда может создать такой большой размер модульных тестов.

Ответ 5

Гросс. Я тоже должен был с этим справиться. Думаю, что лучше всего опираться на яркие инструменты, которые вы, вероятно, не хотите использовать (например, NUnitAsp), чтобы получить существующий код под тестами. Затем вы можете начать рефакторинг, в то время как эти инструменты не будут разлагаться на вашу кодовую базу.

Затем, как вы рефакторинг, напишите больше логических модульных тестов на новые, тестируемые части, которые вы создаете, и постепенно удаляете исходные тесты.

Ответ 6

Удачи вам в этом... Поскольку у вас мало опыта написания модульных тестов, я рекомендую вам сначала попытаться получить хотя бы некоторый опыт. В противном случае, вероятно, вы проведете тестирование TDD/unit в Лондоне и, возможно, представите новые ошибки в системе, которую вы пытаетесь выполнить unit test. Лучший способ получить опыт - найти кого-то опытного, кто может вам помочь.