Внедрение модульного тестирования и приемочного тестирования в середине проекта - PullRequest
2 голосов
/ 23 сентября 2010

У меня сейчас много головных болей при ведении сайта прямо сейчас. Чаще всего вещи заканчивали ломаться после нескольких обновлений. Этот сайт был создан двумя разработчиками в нашей команде, а затем передан мне. Мне было интересно, будет ли нормально пройти модульное и приемочное тестирование, учитывая, что я на полпути к завершению проекта.

Потребовалось бы много времени, чтобы написать тесты сейчас? Будет ли это практично или для этого есть другие методы тестирования?

Ответы [ 2 ]

2 голосов
/ 23 сентября 2010

Никогда не рано вводить тестирование, и чем раньше вы это сделаете, тем скорее вы начнете находить ошибки.

Я бы начал с тестирования с двух разных точек зрения. Во-первых, если у вас есть несколько достаточно автономных классов Java, используемых для таких вещей, как бизнес-логика и обработка данных, я бы начал создавать тесты JUnit для них, чтобы выявить проблемы внутреннего кода.

Во-вторых, я хотел бы создать тесты для случаев использования, определенных бизнесом. Скорее всего, это будет сделано в чем-то вроде Selenium, потому что вы хотите, чтобы тест следовал взаимодействию с веб-сайтом, как указано в сценариях использования. Оставьте закулисные песчаные тесты JUnit за кулисами. Это подтверждение высокого уровня функциональности.

Все это займет время, и маловероятно, что руководство позволит вам делать только тестирование в течение пары или недель или более. Вместо этого наиболее вероятный способ справиться с этим - делать это по ходу дела. Размещайте ваши цитаты по времени для исправлений и новых функций, позволяющих писать тесты. Помните, что написание тестов может занимать 50% и более времени, особенно когда вы начинаете их заполнять. Время немного отступит, когда у вас будет широкий набор пакетов, но даже тогда некоторые тесты сложнее написать, чем код. Но они того стоят.

0 голосов
/ 23 сентября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...