Хороший способ написания тестов - повысить ответственность. Если разработчик должен объяснить кому-то точно , почему они не написали модульные тесты, они с большей вероятностью это сделают. Большинство компаний, в которых я работал, требовали, чтобы любой предложенный коммит в транк был проверен другим разработчиком до коммита, и чтобы имя рецензента было включено в комментарии коммита. В этой среде вы можете сказать своей команде, что они не должны позволять коду «проходить» рецензирование кода, если не проведены юнит-тесты.
Теперь у вас есть цепь ответственности. Если разработчик фиксирует код, не называя рецензента, вы можете спросить его, кто просматривал код (и, как я понял, трудно сказать «никто» своему боссу, когда ему задают этот вопрос, это не весело!). Если вам станет известно о том, что код фиксируется без юнит-тестов, вы можете спросить и разработчика и рецензента кода, почему юнит-тесты не были включены. Возможность задать этот вопрос побуждает рецензентов кода настаивать на модульных тестах.
Еще один шаг, который вы можете сделать, это установить хук коммита в вашей системе управления версиями, который отправляет по электронной почте всю команду, когда коммит сделан, вместе с файлами и даже кодом, который составлял коммит. Это обеспечивает высокий уровень прозрачности и побуждает разработчиков «следовать правилам». Конечно, это работает, только если масштабируется до количества коммитов, которые ваша команда делает за день.
Это скорее психологическое решение, чем техническое решение, но оно хорошо сработало для меня при управлении командами разработчиков программного обеспечения. Это также немного мягче, чем резиновый шланг, предложенный в другом ответе. : -)