Как TDD сравнивается с функциональными языками программирования?

Question

Как TDD отличается от языков функционального программирования, таких как F # и Erlang?

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

Есть ли у этих двух сходства, или я просто немного обдумал это?

Answer 1

Дизайн программного обеспечения v Методология разработки

Они ортогональны.

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

Answer 2

Я думаю, что TDD и функциональное программирование (FP) отличаются тем, что TDD является методологией, а FP - парадигмой программирования.

Я бы сказал, что FP помогает при практике TDD, поскольку FP побуждает вас делать вещи детерминированными, когдавозможный.Детерминированные функции гораздо проще тестировать, чем недетерминированные.

Answer 3

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

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

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

• Наконец, есть несколько хороших автоматических инструментов для тестирования функциональных программ. Для F # у нас есть FsCheck (который основан на QuickCheck, известном из Haskell). Они извлекают выгоду из различных свойств функциональных программ.

Итак, они оба имеют разные цели и, по сути, разные вещи, но есть некоторые хорошие отношения (возможно, такие как чай и чайник :-), они совершенно разные вещи, но очень хорошо работают вместе!)

Answer 4

Вы правы в том, что при написании функциональной программы вы можете использовать эквациональные рассуждения для получения определения функции. Однако такое рассуждение, как правило, не существует в какой-то ограниченной форме (например, в тестах), поэтому, как правило, это не тот случай, когда функция проверена на правильность способом, который проверяется машиной или человеком. Конечно, можно использовать TDD с функциональными языками (например, используя любую .NET-совместимую библиотеку TDD с F #), чтобы проверить, что функции были получены правильно, но есть и другие стратегии тестирования, которые могут быть более уникальными для функциональных языков, такие как использование QuickCheck для рандомизированной проверки спецификаций.

Answer 5

Я думаю, что подобное чувство между двумя происходит из-за того факта, что в обоих случаях функции должны быть детерминированными. Функции FP не должны иметь побочных эффектов, а побочные эффекты в тестовых функциях для объектно-ориентированного кода должны быть удалены путем введения заглушек.