×Закрыть

А вы пишете тесты?

Собственно вопрос:
1) Пишут ли разработчики тесты?
2) Если да, то какое покрытие кода?
3) Какого рода тесты? На моках, или стабах, или чесно лазят в базу и создают там все что надо и тд.

Теперь более приземленные вопросы:
4) Какими средствами пользуетесь? Особенно интересно с точки зрения java (JEE) разработчика.
5) Если на проекте есть javascript, то как он тестируется, если тестируется

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
1. Пишут
2. Надо стараться приближаться к 100%
3. И на моках (быстрые юнит-тексты), и с записью и базу и всем остальным (медленные интеграционные тесты). Для интеграционных тестов поднимается база в памяти, после тестов она, натурально, гасится.
4. JUnit, EasyMock, встроенная поддержка Spring

5. Есть, не тестируется, что, кстати, большой минус.

1. да, но далеко не все у нас
2 .не очень большое. Тяжело посчитать: критические вещи, то, что используется во многих местах, и то что упало несколько раз.

3. юнит тесты и функциональные. Sqlite база где возможно, где невозможно моки и стабы. В одном проекте была необходимость проверять корректность SQL, приходилось лазить в базу.

4. RSpec. В .Net проекте тесты не писал, но прогонял часто используемые вещи через Pex ( research.microsoft.com/...s/projects/pex )

5. Jasmine использовали в одном из проектов, сейчас нет такой необходимости.

Когда тесты запускаются больше нескольких минут желание запускать их особого нет. Я использовал специальный rake task чтоб коммитилось только после удачного исполнения тестов.

1) юниты — есть, причем по инициативе разработчиков, интеграционные\функциональные (которые честно ходят в базу) — есть, так как они часть официально процесса разработки в компании, автотесты UI — есть местами, зависит от проекта или модуля
2)покрытие от 0% до 75% — зависит от проекта, модуля и т.д. Есть проекты, где определенный процент покрытия требует заказчик. А в сейлс демах, которые длятся 3 недели — наоборт, на тесты никто не даст тратить время
3) юниты на jUnit + Mockito, интеграционые — на внутрикорпоративном фреймворке, автотесты UI — на селении, но их пишут специальные QA-нинзи, а не девы
4) см выше

5) js есть, его много, тестируется пока только вручную или селенией. Юнитов пока нет.

Пишу под Андроид, тесты не использую. При осмысленном написании кода качество не падает, а время выигрывается. Те баги, которые могли бы быть отловлены тестами, отъедают гораздо меньше времени, чем заняло бы написание тестов.

Проект повністю на джаваскріпті, тестами покрито більша частина (70-80%), використовується JSUnit, зміни часто, тому тести досить сильно помагають.

1. пишу в основном там где используются всякие рассчеты (уровень BLL, сервисных апи)
2. покрытие 30% масимум
3. на DAL без всяких моков и стабов, внутри транзакци создают в базе, потом манипуляция данными и откат. так как много дженерик методов, то это сокращает кол-во тестов.
4.nUnit (но я дотнетчик)

5. жабаскрипт никак тестами пока не покрываем, хотя в последнее время кода на скрипте больше чем на си шарпе

1) да
2) зависит от проекта — было и больше 90%
3) все подрят, зависит от проекта
4) силениум

5) никак

4) силениум

А при сборке? Или вайтбокс тестов нет?

при сборке гоняем все что есть, тк часто tdd- то есть много.
junit + dbunit в основном сейчас

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

Иногда, пишу тесты для подсистемы, перед крупными рефакторингами — когда есть возможность проверить некие «эталонные данные» на выходе

1. Конечно пишем, еще и TDD используем.
2. Юнит-тестами покрываем где-то проценов 70-80;
3. Unit тесты; UI тесты. Моки стараемся не спользовать, только в крайних случаях. Используем стабы. UI тестируется с помощью специального фреймворка. В базу не лазим. Слой который общается с базой не тестируется. Хотя можно бы было использовать какую-нибудь тестовую базу (не production!!!) для того чтобы оттестировать слой, который общается с базой. Думаем об этом.
4. MSTest; TypeMock (редко).

5. нету.

А какая мотивация против использования моков?

А зачем усложнять себе жизнь?

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

Осваивайте «найтли билд» и автоматизированный запуск/верификацию тестов после него.

Что подразумевается под «верификацией тестов»?

Когда выходные данные тестов сравниваются автоматом с эталонными данными и генерируется ошибка (лог/почта/прочее сообщение), в случае проблем.

А все тесты запускать и не нужно. Запускайте только те тесты, которые проверяют то что менялось. Запускайте тесты часто и сразу увидите что поламалось.

Второй вариант не коммитить до билда и до того момента пока не пройдут все тесты. Ждать конечно же не нужно, просто запустить это все на отдельном сервере после чего заниматься своим делом. После того как загориться зеленый свет — код комитится. Ключевые слова здесь: Team City, Jenkins (Hudson).

Ждать конечно же не нужно, просто запустить это все на отдельном сервере после чего заниматься своим делом.

А как ваш код попадает на тот отдельный сервер? Его надо закоммитить?

После того как загориться зеленый свет — код комитится.

То есть если сборка раздолбана серьезно, то все команда сидит и ждет пока ее не починят (ну или помогает чинить, не суть важно)

Второе, мне надо проверить «что мого поламать МОЙ коммит». То есть или на каждого дева свой СиАй или все стоят и ждут пока один не исправит все что сламал.

А как ваш код попадает на тот отдельный сервер? Его надо закоммитить?

Только вчера сам узнал, что есть такая штука pre-commit. И действительно, сначала измененные файлы попадают на билд-сервер, запускаются тесты и в зависимости от результата commit происходит или нет. О как.

А ссылку на «почитать» можете дать?

Спросил: www.jetbrains.com/...yed_commit.html . Но это решение конкретно для TeamCity.

можно смотреть в сторону тест серверов и кластеризации запуска тестов если критично запускать все

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

Просто по спрашивав у знакомых, получилась ситуация, что у одних чуть ли не аксессоры тестируются, а у других покрытия мение 10% (чисто для виду), отсюда и возник вопрос топика.

встречал упоминания именно кластеризации тестов-запуск в облаке- разделять на порции и пускать на множестве серверов.

посмотрите на Selenium Grid

Спасибо, посмотрим.

А мне кажется наоборот упрощать. Что вообще такое стаб? Вики говорит что это тоже что и мок но только для метода. У вас такие стабы юзаются?

Ок, согласен, так а в чем усложнение?

По ссылочке мок, почитайте раздел Limitations.

Там два конкретных аргумента:

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. — мой ответ — и как здесь спасают стабы?

Юнит тесты — юзаем easymock, стараемся покрыть все.

Функциональные — честно пишем в базу и потом проверяем что записано, используем селениум для юай функциональных тестов и loadrunner для тестирования нагрузки и тоже для функциональных тестов.

2. Большое

Это сколько (в процентах)? Если это не корпоративная тайна.

Подписаться на комментарии