Какой тест для какой части программного обеспечения?

Question

Я новичок в TDD и хочу знать, какой тип теста мне нужен для какой части программного обеспечения.

В настоящее время моя команда создает относительно сложный редактор на платформе Netbeans, где мне нужно интегрироватьвнешний редактор, а также писать собственные вещи.Итак, как я могу сделать тесты лучше всего для графического интерфейса, собственного кода, кода интеграции?Где я могу создавать закодированные тесты и где я должен использовать тестовые примеры и тестеры?

Мы планируем использовать спецификации scala или junit для кодированных тестов.

Спасибо за вашу помощь!

Answer 1

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

В нашем процессе TDD мы просто следуем правилу, согласно которому каждый класс Java должен иметь соответствующий класс JUnit.который содержит метод @Test для каждого метода этого класса Java.Затем мы сопровождаем это «охватом кода», который скажет нам, сколько кода, которое мы фактически написали, было протестировано.Для этого я предлагаю посмотреть на инструмент под названием Cobertura ( ссылка здесь ), который предоставляет нам простой визуальный способ проверить процент нашего кода, который был протестирован.он работает просто путем определения количества строк кода, которые ваш класс JUnit протестировал для каждого класса Java.Это даст вам хорошее представление о том, какие функции в вашем коде были или не были протестированы.Обычно мы стремимся к тому, чтобы около 80% тестируемого кода (легче сказать, чем сделать), однако

сначала рассмотрят возможность написания тестовых случаев для ваших высокоприоритетных функций.

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

надеюсь, это немного поможет.

Answer 2

Это очень субъективно, но я бы посоветовал аккуратно отделить ваш графический интерфейс и написать основательные модульные тесты с интерфейсом между графическим интерфейсом и бизнес-уровнем. Не беспокойтесь об автоматизации тестирования графического интерфейса. Это, естественно, заставит вас создать четкое разделение проблем между слоями.

Answer 3

GUI предназначен для взаимодействия с человеком, поэтому автоматический тест GUI приведет к эпическим сбоям.Если вы хотите правильно протестировать графический интерфейс, вам просто потребуются люди.

Однако вы можете проверить, как ваше приложение будет реагировать на различные действия пользователя.В частности, подумайте, чтобы проверить, как ваше приложение должно справляться с ошибками пользователя (например, когда буквы пишутся только в числовом поле ввода).

Если различие между модульными, функциональными и интеграционными тестами неяснодля вас не беспокойтесь слишком много.Попробуйте проверить столько вещей, сколько считаете нужным (опять же, не забывайте худшие сценарии).Если сомневаетесь, помните, что лучше слишком много тестировать, чем мало.