Как использовать TDD в не очень "тестовой" среде

Question

Я работаю в компании, где ООП ... ну, не запрещено, но, по крайней мере, осуждено как "слишком сложное". Мои коллеги пишут множество функций из более 100 строк, и все они обычно находятся в "funcs.inc.php" или "thing.inc.php ", если они вообще используют какие-либо функции, то часто они этого не делают, так как копирование-вставка быстрее.

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

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

Какой подход вы бы предложили, кроме смены компании?

Answer 1

Я был в этом положении, как в настоящем TDD. Обычно я пишу тесты для интерфейсов других людей, когда это возможно. Затем я знаю, прежде чем запускать свой код, если они сделали одно из многих общих действий, которые делают люди:

1. Сломал API, переименовав или полностью покончив с чем-либо
2. сломал API с тонкими изменениями типов, которые не были замечены
3. отправил токсическую ревизию без проверки
4. Из-за утечек памяти (мой набор тестов известен Valgrind)
5. Блок там, где они никогда раньше не блокировались

Любой из этих сбоев обычно приводит к тому, что я говорю: «Эй, можешь проверить (модуль), я думаю, что он сломался в последней ревизии»

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

Никогда не стоит выходить прямо и говорить: «Послушай, я трачу больше времени на отладку твоего кода, чем на работу самостоятельно», если только тебе это не нужно (т. Е. Твой босс спрашивает о твоей производительности). В большинстве случаев, если вы просто отправляете людям тесты, они счастливы, что получают их. Если вы уже встречаете сопротивление этой идеей, просто постарайтесь никого не обидеть или казаться снисходительным.

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

Answer 2

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

Если они никогда не спрашивают, ну, по крайней мере, ты сделал свою жизнь немного проще.

Answer 3

Я бы посоветовал начать с любой следующей вещи, которую вы должны написать, и попытаться сначала выполнить несколько тестов, а затем написать код для этой вещи. Это может быть исправление ошибки, реализация расширения или новой функции, но идея состоит в том, чтобы попытаться найти способ выполнить тесты до изменения.

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

Answer 4

Можете ли вы сначала написать модульные тесты для собственного кода? Не надоедать другим людям; убедитесь, что ваш код полностью обновлен и проверен модулем.

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

Answer 5

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

Создание макетных функций для библиотек, от которых вы хотите изолировать себя.