Как разработать сложные методы с TDD

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

Чтобы ответить на ваш вопрос, я думаю, что да, в некоторых случаях это не ситуация «2 минуты, пока вы не станете зеленым». В таких случаях, я думаю, это нормально, если у тестов требуется много времени, чтобы они стали зелеными. Но большинство ситуаций - это «2 минуты, пока вы не перестанете работать». В вашем случае (я не знаю, что такое биномиальное распределение), вы написали, что у вас есть 3 аргумента: n, k и p. Если вы сохраните k и p постоянными, проще ли реализовать вашу функцию? Если да, вам следует начать с создания тестов, которые всегда имеют постоянные k и p. Когда ваши тесты пройдут успешно, введите новое значение для k, а затем для p.

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

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

- EDIT - на основе комментариев

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

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

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

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

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

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

класс A { public doLotsOfStuff () // Вызов doTask1..n частный doTask1 () частный doTask2 () частный doTask3 () }

Вам будет довольно сложно разрабатывать TDD, если вы начнете с написания теста для максимальной функциональности (например, doLotsOfStuff ()). Разбив проблему на более управляемые части и подойдя к ней с точки зрения простейшей функциональности, вы также сможете создавать больше дискретных тестов (гораздо более полезных, чем тесты, проверяющие все!). Возможно, ваше потенциальное решение можно было бы переформулировать так:

class A { public doLotsOfStuff () // Вызов doTask1..n общедоступный doTask1 () общедоступный doTask2 () общедоступный doTask3 () }

Хотя ваши частные методы могут быть деталями реализации, это не причина избегать их изолированного тестирования. Как и многие другие проблемы, подход «разделяй и властвуй» может оказаться здесь эффективным. Реальный вопрос заключается в том, какого размера фрагмент функциональности, который можно тестировать и поддерживать? Только вы можете ответить на этот вопрос, основываясь на вашем знании проблемы и собственном суждении о применении своих способностей к задаче.

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

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

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

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

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

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

Даже если методы просто берут часть формулы из более длинного метода, вы получаете преимущество удобочитаемости (имя метода должно быть более читабельным, чем часть формулы. заменяет), и если методы являются окончательными, JIT должна встроить их, чтобы вы не