Разработка через тестирование, модульное тестирование

Question

позвольте мне сначала объяснить, к чему я стремлюсь, с помощью этого вопроса:

Что я за dev? Я парень, который думает о проблеме, пишет код, а затем тестирует его сам. В основном я занимаюсь разработкой веб-приложений, но есть также проекты, основанные на пользовательском интерфейсе (приложения RCP / Swing). Я запускаю свое приложение и нажимаю здесь, проверьте это ... Вы, вероятно, знаете этот "стиль".

Ну, я парень, который пытается улучшить себя с каждой строкой / проектом, и я хочу, чтобы мой код / ​​приложения тестировались прагматично. Я пишу в коде - я хочу проверить в коде.

Итак, я начал для некоторых моих классов / функций использовать модульные тесты (junit 4). Это работает для бэкэнда, где не задействован пользовательский интерфейс - tbh: мне трудно писать большинство тестов. Если мы создаем веб-приложение, возможно, есть взаимодействие с сеансом или чем-то еще. Я думаю, вы поняли.

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

Может быть, это тоже важная часть: я занимаюсь разработкой на Java (85% времени) и PHP / Python (остальное)

Привет

Answer 1

Я нахожу технику, описанную в Диалоговое окно «Смирение» , очень эффективной для пробного вождения моего графического интерфейса. По сути, каждый класс графического интерфейса пользователя разбит на 3 класса и интерфейс: (1) логический контроллер, который определяет, как логика графического интерфейса пользователя (изменение меток, все ли включено? И т. Д.) Полностью тестируема и не зависит от фактического GUI, но зависит от (2) интерфейса представления, который определяет, как логический контроллер будет взаимодействовать с GUI позже. (3) Фактический класс GUI, который является очень тонкой оболочкой для настоящей библиотеки GUI. Наконец, (4) поддельное представление, которое вы используете для тестирования, чтобы доказать, что ваш логический контроллер будет правильно манипулировать GUI.

Поначалу может показаться, что у вас много работы, но я призываю вас попробовать. У меня было очень мало проблем с моими GUI с тех пор, как я начал это делать. Предварительная работа экономит основные головные боли (и время) позже.

Answer 2

Вы можете использовать Selenium для полного внешнего тестирования в любой основной среде тестирования (например, JUnit). Затем придерживайтесь только использования JVM для внутреннего кода, что достаточно просто. Вы должны быть покрыты в этом отношении. С Selenium вы пишете сквозной тест, а не атомный модульный тест по каждому аспекту. Это компромисс с использованием полного внешнего интерфейса для тестирования.

Answer 3

Разработка через тестирование: по примеру , от Кента Бека. Практическое руководство - это основополагающая работа.

Другие, что я бы предложил:

• Разработка через тестирование: практическое руководство Дэйва Астелса
• Книга RSpec Дэвида Челимского и его друзей (включая Дэйва Астелса)

TheRSpec Book представляет следующее поколение - Behavior Driven Development .Если вы заинтересованы в TDD, вас также заинтересует BDD.

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

Answer 4

Существует несколько платформ, позволяющих вам протестировать ваш пользовательский интерфейс, я тестировал пользовательский интерфейс с платформой FEST для моего Swing-интерфейса. Но есть и другие инструменты, которые лучше всего подходят для веб-приложений. Java Source имеет большой список инструментов с открытым исходным кодом для веб-тестирования в Java .