Унаследованный код и юнит тесты: можно вместе!

0 views
Skip to first unread message

Alexey

unread,
Jan 5, 2008, 5:41:54 PM1/5/08
to agile-...@googlegroups.com

Всем привет.

 

Советы от Henrik Kniberg для тех, кто работает с унаследованным кодом, но при этом хочет иметь пополняющийся набор адекватных автоматизированных тестов:

 

http://blog.crisp.se/henrikkniberg/2008/01/03/1199369940000.html

 

Регулярные полезные ссылки на http://links.agileukraine.org/

 

--

Alexey Krivitsky,

 

Olex

unread,
Jan 5, 2008, 7:28:51 PM1/5/08
to Agile Software Development Group, Ukraine
точнее здесь
http://blog.crisp.se/henrikkniberg/2008/01/03/1199386980000.html

есть еще пятый вариант - сгенерить набор тестов при помощи этой штуки
http://www.junitfactory.com

кто-то пробовал? :)

--
Olexandr Kundirenko

Ілля Романенко

unread,
Jan 6, 2008, 9:06:28 AM1/6/08
to agile-...@googlegroups.com
мм интересно насчет JUnit Factory - надо чтобы _кто-то_ попробовал :))

2008/1/6, Olex <olexandr....@gmail.com>:

Serhiy Yevtushenko

unread,
Jan 8, 2008, 2:32:12 AM1/8/08
to agile-...@googlegroups.com
Я пробывал генерить тесты при помощи junitfactory.
 
Плюсы:
1) Для изолированного класса генерит юнит тест с покрытием на 100 %
 
Какие проблемы :
 
1) Требует пересылки исходного кода по незащищенному каналу (что может вызывать вопросы со стороны заказчика)
2) Если код зацеплен, то расцепление делается при помощи моков (встроенных в их фреймворк). Это решеет текущую проблему (отсутствие юнит тестов), но не решает глобальной (зацепленный дизайн со смешанными обязательствами классов)
3) Понимания кода/требований сгенерированные юнит тесты сильно не добавать.
 
 
Коммерческая версия этой штуки стоит весьма и весьма дорого

 
2008/1/6, Ілля Романенко <ilyaro...@googlemail.com>:

Serhiy Yevtushenko

unread,
Jan 8, 2008, 2:50:52 AM1/8/08
to agile-...@googlegroups.com
Есть еще одна стратегия, на мой взгляд, которую проще всего реализовать на практике / поддерживать при наличии большего количества унаследованного кода -
пишите тесты на новую функциональность и на те части, которые изменяються.
 
Этот подход обеспечить то, что тесты покрывают новую функциональность (то есть то, что должно работать хорошо), и на те части, которые чаще всего изменяються (опять таки, там, где тесты нужны больше всего)
 
При этом убирается риск, что время, затраченное на покрытие тестами, будет потрачено на часть, которая не изменяется, и так работает, ...
 
 
Дальше, при работе с легаси кодом 100 % необходимы интеграционные тесты. Одних юнит тестов обычно не достаточно.

 
06.01.08, Alexey <alexeyk...@gmail.com> написал(а):
Reply all
Reply to author
Forward
0 new messages