Собственно вопрос:
1) Пишут ли разработчики тесты?
2) Если да, то какое покрытие кода?
3) Какого рода тесты? На моках, или стабах, или чесно лазят в базу и создают там все что надо и тд.
Теперь более приземленные вопросы:
4) Какими средствами пользуетесь? Особенно интересно с точки зрения java (JEE) разработчика.
5) Если на проекте есть javascript, то как он тестируется, если тестируется
5. Есть, не тестируется, что, кстати, большой минус.
3. юнит тесты и функциональные. Sqlite база где возможно, где невозможно моки и стабы. В одном проекте была необходимость проверять корректность SQL, приходилось лазить в базу.
4. RSpec. В .Net проекте тесты не писал, но прогонял часто используемые вещи через Pex ( research.microsoft.com/...s/projects/pex )5. Jasmine использовали в одном из проектов, сейчас нет такой необходимости.
Когда тесты запускаются больше нескольких минут желание запускать их особого нет. Я использовал специальный rake task чтоб коммитилось только после удачного исполнения тестов.
5) js есть, его много, тестируется пока только вручную или селенией. Юнитов пока нет.
Пишу под Андроид, тесты не использую. При осмысленном написании кода качество не падает, а время выигрывается. Те баги, которые могли бы быть отловлены тестами, отъедают гораздо меньше времени, чем заняло бы написание тестов.
Проект повністю на джаваскріпті, тестами покрито більша частина
5. жабаскрипт никак тестами пока не покрываем, хотя в последнее время кода на скрипте больше чем на си шарпе
5) никак
4) силениум
А при сборке? Или вайтбокс тестов нет?
при сборке гоняем все что есть, тк часто tdd- то есть много.
junit + dbunit в основном сейчас
Тесты не пишу, т.к. малореально тестами покрывать довольно-таки часто-меняющиеся особенности интерфейса и, тем более, реализации. Обставляю весь код всевоможными ассертами, для режима отладки и стараюсь инициализировать все переменные.
Иногда, пишу тесты для подсистемы, перед крупными рефакторингами — когда есть возможность проверить некие «эталонные данные» на выходе
5. нету.
Вот например команда в которой я работаю столкнулась с проблемой что сборка длится более чем 1,5 часа. Проблема еще и в том что не реально запустить все тесты перед каждым коммитом, то есть после большого рефакторинга приходится гадать какие тесты могли бы поломаться или закоммитить и ждать пока свалится сборка (1,5 часа) или пока не закричит кто-то из соседей :).
Осваивайте «найтли билд» и автоматизированный запуск/верификацию тестов после него.
Что подразумевается под «верификацией тестов»?
Когда выходные данные тестов сравниваются автоматом с эталонными данными и генерируется ошибка (лог/почта/прочее сообщение), в случае проблем.
Второй вариант не коммитить до билда и до того момента пока не пройдут все тесты. Ждать конечно же не нужно, просто запустить это все на отдельном сервере после чего заниматься своим делом. После того как загориться зеленый свет — код комитится. Ключевые слова здесь: Team City, Jenkins (Hudson).
Ждать конечно же не нужно, просто запустить это все на отдельном сервере после чего заниматься своим делом.
А как ваш код попадает на тот отдельный сервер? Его надо закоммитить?
То есть если сборка раздолбана серьезно, то все команда сидит и ждет пока ее не починят (ну или помогает чинить, не суть важно)После того как загориться зеленый свет — код комитится.
Второе, мне надо проверить «что мого поламать МОЙ коммит». То есть или на каждого дева свой СиАй или все стоят и ждут пока один не исправит все что сламал.
А как ваш код попадает на тот отдельный сервер? Его надо закоммитить?
Только вчера сам узнал, что есть такая штука pre-commit. И действительно, сначала измененные файлы попадают на билд-сервер, запускаются тесты и в зависимости от результата commit происходит или нет. О как.
Спросил: www.jetbrains.com/...yed_commit.html . Но это решение конкретно для TeamCity.
можно смотреть в сторону тест серверов и кластеризации запуска тестов если критично запускать все
Просто по спрашивав у знакомых, получилась ситуация, что у одних чуть ли не аксессоры тестируются, а у других покрытия мение 10% (чисто для виду), отсюда и возник вопрос топика.
посмотрите на Selenium Grid
А мне кажется наоборот упрощать. Что вообще такое стаб? Вики говорит что это тоже что и мок но только для метода. У вас такие стабы юзаются?
Там два конкретных аргумента:
many mock object frameworks allow the developer to specify the order of and number of times that the methods on a mock object are invoked — ответ: но также позволяют программисту не специфицировать ни порядок ни количество раз.
Mock objects have to accurately model the behavior of the object they are mocking, which can be difficult to achieve if the object being mocked comes from another developer or project or if it has not even been written yet. — мой ответ — и как здесь спасают стабы?
Функциональные — честно пишем в базу и потом проверяем что записано, используем селениум для юай функциональных тестов и loadrunner для тестирования нагрузки и тоже для функциональных тестов.
2. Большое
Это сколько (в процентах)? Если это не корпоративная тайна.
Voicechat: Product в Deftechсереда о 19:30
Sergii Maliarov
Олександр Слинько
Petrychenko Ivan
Тимур Поркуян
Razubajev Yurii
Alex Svetlov
Нестор Иванович
Нестор Иванович
maxdz
gorik gorik
reality_hacker
gorik gorik
maxdz
Gluttton
reality_hacker
anonymous
anonymous
34 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів