Принуждение поблочного тестирования на разработчиках

Если вы не являетесь авторитетным лицом, лучшее, что вы можете сделать, - это убедить их в ценности набора тестов.

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

Попробуйте объединиться с другим разработчиком и показать им преимущества и ясность, которые приходят от написания тестов ПЕРВЫМ. Если вы этого не сделаете, они, скорее всего, напишут весь свой код, заставят его работать, а затем напишут тесты. Так что, с их точки зрения, это будет казаться просто дополнительной задачей, которая не поможет им добиться результата.

Также имейте в виду, что люди часто не понимают, как писать хорошие тесты. Более того, некоторые не знают, как использовать такие инструменты, как jmock, что может привести к тому, что они застрянут и откажутся от написания теста.

Вам не нужно пустое тестирование на словах, вам нужно искреннее модульное тестирование. Это не то, что можно принуждать. Что вам нужно сделать, так это со временем повлиять на ваших товарищей по команде, чтобы увидеть преимущества модульного тестирования и развить культуру модульного тестирования.

Для начала вам нужно понять, что разные люди меняются по разным причинам. В терминах Crossing the Chasm , провидцы будут применять новые методы, потому что они лучше, но прагматики применяют новые методы либо потому, что они решают проблему / боль, которые есть в настоящее время, либо потому, что все остальные принимают ее.

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

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

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

Учитывая, что модульное тестирование улучшает качество кода и программного обеспечения в долгосрочной перспективе, я бы сказал, что да, это хорошая практика, когда ваши разработчики предоставляют модульные тесты - будь то часть некоторых спринт или нет.

Два основных препятствия для модульных тестов, которые я видел:

• разработчики не понимают сути: «зачем нам писать больше кода только для тестирования?»
• «у нас нет времени писать юнит-тесты»

Чтобы ответить на первый вопрос, я полагаю, вам придется обеспечить своего рода демонстрацию / формирование; если вы сможете заставить разработчиков понять, почему юнит-тесты полезны, они им понравятся, и они будут их использовать / разрабатывать; но им нужно понять, почему они полезны: если вы не их начальник, вы не можете заставить людей разрабатывать юнит-тесты.
And, even if you are their boss, they will probably not do the best possible job if they are being forced : unit-testing is often done better if people understand why and how !

To answer the second point... Well, you obviously need to get your developpers some "special" time to developp unit-tests ; it can mean less time to do manual testing, btw.

Another thing is : it is hard to know "what to test", and "how to test" : you will need to explain / demonstrate that to your colleagues : some things cannot be tested, some things don't need to be, and some things are not "unit-testable" -- well, I suppose, unless you software is really well engineered ^^

Сначала поговорите со своим менеджером. Если он убежден, что тестирование - это хорошо, добавьте тест покрытия в свою систему сборки. Если покрытие ваших модульных тестов упадет ниже определенного уровня, вы можете обработать это как неудачную сборку. Это дает вашим коллегам средство измерения, способ увидеть, когда не удается доставить проверенный код.

В вашем случае NCover , кажется, прекрасно интегрируется в CC.NET .

В прошлом я занимал эту должность на многих работах и ​​по контрактам, поэтому я, наконец, разочаровался и принял тьму, отстаивая Разработка, управляемую развитием . 1239] Я обнаружил, что когда большинство менеджеров принимают XP, они предпочитают выбросить документацию, а не выполнять TDD. Программисты в большинстве команд награждаются за быстрые взломы, позволяющие устранить дефект из очереди, и примерно один из десяти менеджеров имеет смелость противостоять высшему руководству, выступая за общее качество продукта, а не за низкое. -line-for-this-квартал способ ведения бизнеса. В конце концов, большинство программных работ, которые платят какую-либо сумму, спонсируются корпорациями, и Фрейд доказал, что корпорации безумны.

Или, по крайней мере, он должен был иметь.

это зависит от вашего контроля версий, но есть программное обеспечение контроля версий, которое позволяет вам запускать сценарии перед регистрацией или перед слиянием с производственной веткой. и он не позволит разработчику проверить, если модульное тестирование не удалось.

No. In my experience, TDD isn't all that useful in practice. I sometimes use it for really general fundamental classes (like geometry or generic data structures) that lend themselves naturally to automated tests. But for UI components or business logic, I find it's more trouble than it's worth.

На эту тему есть замечательная статья Джоэла о программном обеспечении под названием Как сделать все, когда ты всего лишь ворчун . Его стратегии, применяемые к объединенному тестированию, будут следующими:

1. Просто сделай это

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

2. Используйте возможности вирусного маркетинга

   Если вы видите ошибку в чужом коде, напишите тест, который ее запускает и подарить ему оба. Может быть, он понимает вашу точку зрения.

3. Создайте карман передового опыта

   Определите членов команды, которые открыты для идеи, но не совсем уверены, как работать с модульными тестами, и настройте несколько тестовых классов, пока каждый из них не узнает как это сделать. Затем повернитесь к другим. Намного легче установить, когда вы перестанете быть единственным.

4. Нейтрализовать Bozos

   Будут члены команды, которых почти невозможно заставить писать тесты. Может быть, с ними следует справляться, регулярно нарушая их код с помощью нового коммита - а затем указывая на то, что, поскольку у них нет тестов, вам было трудно заметить.