TestMe-ON » ru » faq

FAQ - Часто задаваемые вопросы

Зачем нужно тестировать и за счет чего может повыситься эффективность разработки?

Разработка бывает двух видов.
1. Персональная разработка.
2. Разработка в группе.

1.Персональная разработка.
Даже если у вас все всегда работает, найдется пользователь у которого ваш продукт не будет работать или будет работать иначе. Ваша задача разработчика найти ошибку и устранить. Без тестов Вы, как слепой котенок, идете по цепочке событий отслеживая сбой и хорошо, если у вас есть доступ к компьютеру на котором возникли проблемы, а если доступа нет?.
При использовании тестов, они сами покажут где проблема или значительно сузят ее поиск.
А ошибки могут быть из-за:

  • Несовместимость с новой операционной средой
  • обновления операционной системы
  • железа (материнская плата, видеокарта, жесткий диск и тд)
  • драйверов
  • ошибок в новой среде разработке или в новой версии компонентов.

Где бы не были ошибки их искать и устранять Вам.Тесты очень сильно помогают решить эту задачу.
Кроме поиска ошибок тесты позволяют сделать оценку:

  • Как будет работать ваш продукт в новой операционной среде?
  • На сколько полно и быстро работает Выша программа?
  • На сколько новая среда разработки эффективнее чем существующая?

Кто ответит на эти вопросы и сколько нужно потратить времени без тестов?
Пользователи могут работать с программой не так Вам хочется, а так как Вам даже в голову не придет. И Ваша задача сделать проверку работоспособности программы на любой не корректный ввод или не правильное пользование Вашей программой.

2. Разработка в группе.
Для разработчика:
Если Вы работаете в команде и ваши модули пересекаются с модулями других разработчиков, то постоянно кто-то, что-то поменяет и у пользователя отваливается уже работающий функционал.
Вы занимаетесь работой и вам прилетает претензия, что старый модуль работал, а сегодня не работает.
Без тестов разбираться Вам, кто где накосячил, какую версию исходников из репозитария нужно вытащить и где восстановить функционал.
С тестами же головная боль перекладывается на того кто создал ошибку, это самое важное!
Вы освобождаетесь от дополнительной работы, у вас появляется ВРЕМЯ, которое Вы не будете тратить на исправление чужих ошибок.
Время - самый ценный ресурс, который ничем нельзя восполнить, оно только может тратиться и чем старше становишься тем больше этим проникаешься.
С тестами, если после Вас что-то где-то не работает, это не ваша проблема, пусть ее решает тот, кто ее создал.
Для руководителя:
Если один программист в компании и у него один простой продукт, то мысли «Зачем нужны тесты?» могут появится в голове,но у Вас группа программистов которая использует общие библиотеки, модули, и тестирование становится очень важным этапом разработки.
Как контролировать работу программистов без тестов?
Программист говорит «Все хорошо, все работает». Действительно это так? Какие у Вас есть критерии оценки слов разработчика?
Отчет тестировщика?
Сколько процентов функционала протестирует тестировщик?
У тестировщика есть автоматические тесты?
А у программиста?
Отчет программиста есть по выполненным тестам?
Он сдал работу, на сколько правильно он выполняется и на сколько его код устойчив к ошибочным данным? «Все хорошо, все работает» Вы слышите слова программиста, Вы как руководитель слепо верите словам программиста?
А когда Вы даете задание на изменение/расширение функционала, почему не с первого раза все заработало безупречно? Почему возникают ошибки после слов «Все хорошо, все работает»?
Или Ваша компания придерживается правила «Сделаем релиз, отдадим заказчику, ошибки будем исправлять потом»?.
Если Вы разрабатываете CRM систему, то возможно такой подход будет работать более-менее безболезненно.
Если Вы разрабатываете бухгалтерский\складской учет, то цена вашей ошибки уже будет иметь более существенное финансовое выражение.
Но если вы разрабатываете системы управления промышленным оборудованием, то такой подход не приемлем. Цена ошибки - жизнь человека.
К сожалению многие отделы разработки работают по правилу «ошибки будем исправлять потом», даже при разработке ПО по управлению промышленным оборудованием. И если есть в таких отделах тесты, то в большей части только на бумаге. Потому что программист говорит «Нет времени», «Время наложение тестов больше или равно времени разработки». На данный момент TestMe.Code очень быстрая система наложения тестов на код. Сделайте тайминг. Засеките время сколько программист будет писать класс, а потом сколько времени понадобится наложить тест на класс.

Бонус!
Ввод параметров для функционального тестирования в TestMe.Code может вводить не только программист, но и тестировщик.

Полное тестирование очень усложняет и увеличивает время разработки

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


А когда пишите, Вы проверяете свой функционал?
Так сделайте сразу тест, и отлаживайте код сразу с помощью тестов.
Можно не делать все и сразу.
Решили проблему, пока в нее погружены наложили тесты на критические узлы, на то что сделали и все!
Тестирование должно помогать, а не мешать или раздражать.
И потихоньку, потихоньку, не заметно тестами покроется весь Ваш код и даже больше. Тестами покроется функционал сторонних компонент, код среды разработки и проверка функционала операционной среды и сервера баз данных .
Лично для меня тестирование имеет очень сильный эмоциональный стимул. Это просто приятно когда по нажатии на кнопку видишь, что твоя программа безупречна. Конечно, при доработке и внесение изменений в отлаженный код, могут быть ошибки, но до того момента, пока Вы не наложите тесты. У каждого наверно есть «червячек» который не дает делать тесты, это вера в свой безупречный и правильный код. Зачем я буду делать тест, на то что идеально и правильно работает? Знакомо? Но почему существует отладка если программист с первого раза пишет правильный и идеальный код? Вера в свою исключительность и гениальность мешает делать тесты. Да, ты гений, ты молодец, у тебя самые лучшие программы и уникальнейшие, самые лучшие в мире алгоритмы, так зафиксируй ее результат с помощью тестов!

Кроме этого в TestMe.Code проверяет не только правильные ответы: 2 2=4.
Вы можете проверить как будет вести функционал при вводе не правильных данных: 2 'B'=?

Чем лучше TestMe.Code тестирования в DUnit ?

Хочется сразу ответить как в известном анекдоте

- Чем лучше TestMe.Code, чем DUnit?

- TestMe.Code лучше Чем DUnit. :-)

А если серьезно, то очень многим.

1. Скорость. Самое важное для меня качество, это скорость наложения тестов.

2. Постепенное наложение тестов. Написал код, отладил, наложил тест, можно только на один метод, можно сразу на все. И что самое для меня важное, можно просто и легко добавить нужные методы для тестирования.

3. Режим внешних параметров для тестирования. С помощью внешних параметров программист освобождается от скрупулезного и длительного тестирования функционала. Программист, даже самый гениальный, всегда подставит параметры для тестирования меньше, чем начинающий тестировщик. При этом он часто берет «удобные» для себя данные. Тестировщики чаще берут как раз «не удобные» данные, что позволяет с помощью тестировщиков более полноценно протестировать функционал.

4. Отсутствие отдельных юнитов и приложений для тестирования. Но если нужны отдельные модули и отдельные классы тестирования вы можете их создать, смотрите Где писать методы для регистрации тестов

5. Наглядность. Очень удобно когда код теста лежит рядом с основным функционалом.

6. Возможно тестирование как текущего объекта, так и можно создать новый объект.