Итак, тестирование в жизни программиста.
Все знают что такое тестирование... или, по крайней мере, так думают :) Написано довольно много книг и статей об этом, выдуманы методологии и практики (ну например TDD) и даже заложены базовые механизмы в "недра Java". И во всех книгах\статьях\презентациях наперебой утверждают что это круто (в смысле unit тестирование), что это жизненно необходимо, и вооще - JUnit спасет мир.
Во как!
И что?!
В реальной жизни все как то не так «получается». Ну я бы сказал, совсем не так… Ну вот видел не мало проектов, самого разного масштаба и уровня… и не в одной организации работал…. И в подавляющем большинстве с тестированием как то не очень складывалось (!с модульным (unit) тестированием, отдел тестирования\QA здесь не обсуждается!).
Возникает резонный вопрос: «Почему так?». Ну действительно, «не самые глупые» люди пишут что «вот так» надо делать и будет вам счастье, а на практике ну совсем не так (может никто не хочет счастья?).
К чему это все? На данный момент, мне повезло – попал на проект, где к тестированию относятся довольно серьезно, и множество теоретических знаний, наконец то, можно применить в «боевых» условиях. Я не имею ввиду периодические попытки написать там какой то тест, и забивание на это через пару недель; а говорю про постоянное участие в процессе всех разработчиков.
А если есть опыт, то есть чем поделиться :) Заодно, будет чего вспомнить через годик-другой.
Так что, продолжение следует…
И на последок:
Вообще то, Unit тестирование в подавляющем большинстве проектов выгладит довольно интересно (я бы сказал смешно):
Шаг1. Старт проекта. Вот оно! Наконец то проекту дали зеленый свет, запустили и после недолгого раскачивания (усилиями PM и TL) разработчики начали творить.
Шаг 2. Паровоз набрал скорость и уверенно несется в светлое будущее (ну это, как в старых фильмах – облако пара, стук колес и веселый гудок). Программисты кодят, клавиатуры трещат и номер ревизии в SVN превысил число 1000. И тут есть 2 варианта:
2.1. Какой нить разработчик тихим и неуверенным голосом предлагает писать тесты…
2.2. PM (или TL) прочитав умные книги, принимает решение «Первое - Тесты это круто, полезно и без них никуда! И второе – тесты надо писать!»
Шаг 3. Пишем юнит тесты! Если разработчика из п.2.1 удалось проигнорировать, то этот пункт можно пропустить. Если это был авторитетный коллега или товарищ PM, то такое замечание проигнорировать не получится – надо писать! И пишут.
Шаг 4. Конец итерации. PM с гордым видом отчитывается перед заказчиком/руководством, а разработчики, с не менее довольным видом, пьют пиво и хвастаются, что все у них получилось и даже в сроки поместились.
Шаг 5. Проходит 1-2 итерации и начинается, ну допустим 4-ая. Поддерживать старые тесты становиться накладно – бизнес логика уже серьезно поменялась, и вообще… «что это за дела?! Надо дописать маленькую штучку, а тут тебе еще и чужие тесты поправить, а там черт ногу сломает, и еще много чего надо…» Вообщем на тесты начинают забивать. Тут вариантов довольно много:
1.Проявить смекалку и поправить тест, так чтобы он «хоть как то» проходил
2.Закоментировать надоедливый участок теста.
3.Ну в конце концов, исключить тесты из компиляции – шоб никто не заметил, что они
уже 2 недели не то, что не проходят, а даже не компилируются.
Проходит немного времени (на самом деле, не так уж мало) и наступает шаг... ну допустим, 101. Итак:
Шаг 101. Сроки cдачи проекта оказались не такими уже и далекими, и вот уже остались считанные месяцы. Предыдущие итерации сдаются с опозданиями, и все больше и больше планируемого функционал приходится переносить «на потом». И вооще, красивый паровоз (см п.2) превратился в невыразительную груд металлолома, которая ползет с черепашьей скоростью, руководство начинает накаляться, а разработчики косо посматривают друг на друга. И начинается… да по разному бывает.
Может быть команда овертаймит, BA сводят требуемый функционал до минимума, и проект, хоть и с небольшими задержками, но все же сдается, и все с облегчением вздыхают и дружественно хлопаю друг друга по плечу.
Могут быть более тяжелые случаи: отношение с заказчиком накаляются до придела, в команде начинает пахнуть жаренным. Могут даже начаться исправительно-воспитательные мероприятия (а если проще - репрессии).
Что касается тестирования – всегда находятся люди, которые скажут «это все потому, счто у нас тестов нету», в особо тяжких случаях «это все потому, что на тесты у нас забили». Ну действительно, надо же чем то объяснить эту не протсую ситуацию. В некоторых случаях делается отчаянная попытка реанимировать код в папочке test и дописать туда что то новое.
Так или иначе, проект заканчивается. В большинстве случаев, заканчивается трудно, но в целом удачно. Но про тесты остаются вот примерно такие воспоминания: «Мы пытались, но у нас не получалось» и «все равно они ничего не дали».
Конечно же, бывают проекты, где unit тесты пишется регулярно, где не срывают сроки, где реальный функционал соответствует требованиям заказчика и т.д. но я, к великому сожалению, не участвовал в таких. :)
я, не смотря на то, что ФИДОшник со стажем, не буду писать ИМХО перед каждой строчкой. поэтому напишу с самого начала -- мнение мое субъективно и основано исключительно на собственном опыте. а опыт мой скорее говорит о том, как делать не нужно, нежели наоборот.
ОтветитьУдалитьимею я что сказать по данному вопросу. все дело в человеческой лени. да-да, в самой обычной и самой банальной лени. она проявляется по чуть-чуть в разных местах, что сводит процесс разработки, тестирования и документирования к такой умопомрачительной стоимости, что меньшим злом является ничего из описанного не делать. как это работает? весьма просто
1) люди ленятся вникнуть в теорию или чего его думать -- трясти надо. ну правда, зачем читать какие-то талмуды по ТДД если и так все понятно? пишем тест, потом пишем код. проходит -- хорошо, нет -- смотрим где ошиблись, поправляем тест или код и опаньки! зачем тут книжки? какая теория? поехали! за бортом часто остается понимание, что такое есть юнит-тестирование, что такое есть интеграционное тестирование, зачем нам мок-объекты, когда нам нужны реальные данные, а когда и главное ПОЧЕМУ они нам категорически не нужны.
2) юнит-тесты вещь в себе. при этом чисто внутренняя. она стоит отдельно от кода проекта. поэтому ее можно написать быстро, как попало и можно не документировать (про документацию ниже). зачем тут сложные иерархии, дизайны и паттерны -- погнали все в одном методе. ну в двух. и пусть весь мир подождет. когда к 101му шагу нужно что-то поддерживать... ой-вэй! какой мудодяй это писал? ой, это писал я... а что же я имел ввиду? а хз! ф топку не рабочие тесты.
3) документация. сначала все понятно. имена классов самоговорящие, имена методов еще более самоговорящие, методы простые вызовов не много, иерархия из трех наследников максимум. когда иерархии вырастают до сотен наследников, а вызовы методов переваливают за тысячи... уже довольно сложно понять, что делает тот или иной самодокументирующийся метод. но когда мы пишем этот метод, все ведь понятно, нам не нужна документация.
и вот последовательно выполняя все три шага, мы сводим на нет пользу дизайна, тестирования и документации. есть мнение, что все от лени. если не лениться все делать дольше и правильнее, то потом все будет проще и легче. а что до ТЛев и ПМов -- так учитесь давить авторитетом. это довольно просто. нужны только аргументы, с которыми невозможно спорить, цифры, факты и уверенность в собственной правоте. это работает.
Приветствую тебя, мой единственны читатель! :) Вижу, что на выходных без инета с техническим чтивом не обошлось :)
ОтветитьУдалитьПо поводу комента: эт конечно правильно, только есть одно дополнени... Лень – это всем известная черта характера(если можно так сказать), из за которой человек стремится к "ничего не деланию". Ну, покрайней мере, как это я себе понимаю. А еще есть неумение, точнее "незнание как пользоваться инструментом". Это когда у человека есть микроскоп, а сделать он с ним ничего не может (даже если хочтел бы).
Конечно понятно, что не все получается идеально, как хотелось бы (или как пишут в умных книжках), но все сваливать на лень, тоже не дело - в конце концов, чем то ведь отличается хороший разработчик\ПМ\ТЛ от "так себе", и чем то ведь отличаются хорошие проекты от кризисных(из за которых и просыпаться утром не хочется):( И хотелось бы хоть чуть чуть понимать чем… А на практике, по моему, не все зависит от "начитанности" или "не ленивости" участников… Хотя зависит, конечно, многое :)
Это в общем, а в часности:
1. Лень можно лечить кнутом и приником. Есть превеликое множество способов поставить работников в "неудобную позу", вопреки их желанию (начиная от "ходить на работу" и заканчивая писать руками и думать головой а не ногами и опой соответсвенно). И есть довольно много способов объяснить человеку "как делать" так, что он будет это делать это именно так, "для себя" и еще другим про еэто рассказывать :)
2. По поводу незнания, ну тут многое зависит от того, как с "учебой или учителем повезло". Бывает на пальцах раскажут про "штуку полезную" – ты ее юзаеш, и только через пару лет узнаеш то енто оказывается, принцип в проектировании есть такой, по умному "single responsibility" называется. А бывло смотриш что на проекте творится и думаеш, как к этому гавнищу можно применить то, о чем тот умный дядя писал… а еще обязательно умники найдутся, которые посоветуют забить на это, и поменьше читать умные книги.
3. И по поводу "давить авторитетом" - недавно вот был проект где "ни вдохнуть, ни выдохнуть" времени не было – так все были заняты замаливанием грехов перед здачей (а за 2 года их накопилось не мало). Тут как то и "авторитет расправить" не получалось. К томуже, далеко не всегда хвататет уверенности и желания чего нить объяснять и доказывать (хотя идеи стоящие).
привет-привет.
ОтветитьУдалитьпока у меня еще есть примерно час до поезда, отвечу :)
действительно, ты совершенно прав, не все зависит он "не лености" участников проекта. действительно не все. но по-моему именно лень является первопричиной. остальное вторично. хотя бывает и так, что в проекте все участники не опытны. это плохо. поэтому я за разнородные команды. с участием джуниров. это моя мечта для моего проекта.
теперь по пунктам
1. большая ошибка. нельзя. человека нельзя заставить делать работу хорошо. можно ли его мотивировать? можно. но только положительными средствами, террором не выйдет долгосрочного результата. посмотри на последствия СССР. мы с тобой говорили
2. да. это действительно проблема. что делать? распространять информацию. идеальным местом была бы харьковская Java User Group. но ее нет, и скорее всего не будет. есть различные бесплатные мероприятия типа coffee-and-code. я туда хожу и выступаю с докладами. когда успешно, когда - не очень. собственно группа приглашает к сотрудничеству. мне хотелось бы видеть харьковское комьюнити, где можно задать вопрос и получить ответ. как в реале, так и в виде сайта-форума. и мне все-равно имени кого оно будет и как будет называться. главное, чтобы оно было. и работало конечно
3. а в данном вопросе все очень просто. либо ты эскалируешь проблему, либо нет. когда меня что-то беспокоит, я поднимаю шум. большой или маленький, в установленной форме или нет, но я это делаю. всегда. и я напоминаю о проблеме до тех пор, пока ее не станет проще решить, чем в очередной раз меня слушать. вопрос не в том, доказывать или нет. вопрос в том, делать свою работу максимально хорошо или забить. я не умею забить