#java #тестирование
Начнём с того, что я новичок, пользуюсь IDEA. Интересуюсь, как разработкой оффлайн приложений, так и web-, даже про Android был бы не против, что-нибудь услышать, хотя и меньше, чем про первые два варианта. Напишу сначала, что я знаю о тестировании: 1) В некоторых книгах (и не только) рекомендуется такой подход к программированию, при котором перед тем, как писать непосредственно код, пишутся тесты. Если я правильно понял, тесты пишутся ко ВСЕМ классам, которые будут в коде. Но во первых, написание теста к классу требует такого же времени, что и написание самого класса, а иногда и гораздо большего. Во вторых, в тех ситуация, которые я учёл, класс будет функционировать исправно (за исключением опечаток), а в тех ситуациях, которые я не учёл, тест будет проходится успешно (т.к. они не заложены в тест). И в третьих, иногда не знаешь как будет выглядеть некий класс, до тех пор, пока его не реализуешь, более того, и после реализации будет много раз видоизменятся, иногда кардинальным образом - например: попробовал один подход - скорость отработки низкая, попробовал совершенно другой (с другим набором классов и интерфейсов) - выше. Так вот стоит ли прибегать к такому подходу? И как быть с учётом всего, выше написанного? Меня как-то панический страх берёт писать тесты все геттеры/сеттеры... 2) Слышал про автотестирование... даже видел обрывок записи, где записывался макрос мыши, как для автоматической прокачки персонажа в играх. Но знаю крайне мало, то, что мне попадалось выглядит сложно и непонятно, а самое главное не ясно, нужно ли это вобще... Просветите, как новичку воспользоваться автотестированием в различных ситуация (офф, web)? Какие программные инструменты для этого использовать? Какой русскоязычной литературой можно руководствоваться? 3) Может я ещё что-то упустил в области тестирования... Буду рад любым наставлениям ;)
Ответы
Ответ 1
есты пишутся ко ВСЕМ классам писать тесты абсолютно на все - не самая здравая идея. в тех ситуация, которые я учёл, класс будет функционировать исправно не факт. У вас же нет никакой гарантии, что вы правильно реализовали "то, что учли". Проверить это как раз помогут тесты в тех ситуациях, которые я не учёл, тест будет проходится успешно (т.к. они не заложены в тест) разработчик обязан знать, что должен делать тот или иной его класс, соответственно, тестировать свои классы он должен на предмет соответствия этому "предназначению". Следовательно, описанная вами ситуация не имеет смысла иногда не знаешь как будет выглядеть некий класс, до тех пор, пока его не реализуешь см. выше - разработчик должен знать, что будет делать создаваемый им класс, и тестировать его именно с этой точки зрения. Следовательно, тестированию не особо интересны детали реализации этого класса (и возможные изменения в этой реализации) И наконец, не сочтите за занудство, но выглядит ужасно: не "координальным", а кардинальным, и не "просвятите", а просветитеОтвет 2
Важна мера во всем. Тестируются обычно сложные случаи. А так вообще все тестировать никаких сил не хватит. Потом ведь надо будет писать тесты тестов (я серьезно). К тому же тестирование бывает разным: юнит тесты, нагрузочное тестирование, функциональное тестирование и т.д. Не зря среди прогерской братии есть специальность тестировщик/тестер. Прогер должен тестировать конечный результат своего труда. Скажем написали некий класс/иерархию выполняющую допустим скачивание контента из сети. Логичным было бы написать юнит тест проверяющий идентичность скачанного со скачиваемым. В общем идея проста: Вам мудрое руководство поставило некую задачу; Вы ее решили; Теперь надо доказать, что решение работает. Для этого пишете юнит тест (серию юнит тестов) доказывающих работоспособность вашего решения; Показываете руководителю; Профит. P.S. Касательно бинов. Если вам поставили задачу написать бины - значит придется писать юнит тесты на ваши бины. Такова се ля ви :)Ответ 3
Вот хороший плагин для Eclipse, который определяет уровень, насколько ваш код покрыт тестами. http://eclemma.org/
Комментариев нет:
Отправить комментарий