Хорошо это или плохо, что набор тестов для быстрой проверки соответствует реализации?

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

Ответ Ивана касается модульных тестов, в то время как вы говорите о тестах свойств, поэтому давайте проигнорируем его.

Dfeuer говорит вам, когда приемлемо отражать реализацию, но не говорит, что делать для вашего варианта использования.

Распространенной ошибкой в ​​тестах на основе свойств (PBT) является сначала переписывание кода реализации. Но это не то, для чего нужны PBT. Они существуют для проверки свойств вашей функции. Эй, не волнуйтесь, мы все делаем эту ошибку в первые несколько раз, когда пишем PBT :D

Тип свойства, который вы можете проверить здесь, заключается в том, является ли ответ вашей функции согласованным с ее вводом:

if SUT.shouldDiscountProduct p t 
then isJust (userDiscountCode p) && isJust (productDiscount t) 
else isNothing (userDiscountCode p) || isNothing (productDiscount t)

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

Но вы можете найти и другие типы недвижимости! Например. инвариантность свойства:

SUT.shouldDiscountProduct p{userDiscountCode = Nothing} t == False
SUT.shouldDiscountProduct p{productDiscount = Nothing} t == False

Видишь, что мы здесь сделали? Мы зафиксировали одну часть ввода (например, код скидки пользователя всегда пуст) и утверждаем, что независимо от того, как все остальное меняется, вывод остается неизменным (всегда ложным). То же самое касается скидки на продукт.

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

shouldDiscountProduct user product =
  if M.isNothing (userDiscountCode user)
     then False
     else if (productDiscount product) then True
                                       else False

shouldDiscountProduct' user product
  | Just _ <- userDiscountCode user
  , Just _ <- productDiscount product
  = True
  | otherwise = False

SUT.shouldDiscountProduct p t = SUT.shouldDiscountProduct' p t

Что читается как «Независимо от ввода, переписанная функция всегда должна возвращать то же значение, что и старая функция». Это так здорово при рефакторинге!

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

Обратите внимание, PBT не враг модульных тестов, они действительно хорошо сочетаются друг с другом. Вы можете использовать 1 или 2 модульных теста, если это заставляет вас чувствовать себя более уверенно в отношении фактических значений, а затем написать тест (ы) свойств, чтобы подтвердить, что ваша функция имеет некоторое поведение независимо от ввода.

По сути, единственные случаи, когда проверка свойств имеет смысл сравнивать две реализации одной и той же функции, это когда:

1. Обе функции являются частью API, и каждая из них должна реализовывать определенную функцию. Например, мы обычно хотим liftEq (==) = (==). Поэтому мы должны проверить, что liftEq для определяемого нами типа удовлетворяет этому свойству.

2. Одна реализация заведомо правильная, но неэффективная, а другая эффективная, но не заведомо правильная. В этом случае набор тестов должен определить заведомо правильную версию и сверить с ней эффективную версию.

Для типичной «бизнес-логики» ни один из них не применим. Однако могут быть некоторые особые случаи, когда они это делают. Например, у вас могут быть две разные функции, которые вы вызываете при разных обстоятельствах и которые должны согласовываться при определенных условиях.

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

Чтобы решить эту проблему курицы и яйца, тесты строятся на следующих принципах:

• Tests feed predefined inputs and check for predefined outputs. Nothing "random". All sources of randomness are considered additional inputs and mocked or otherwise forced to produce specific values.
  • Sometimes, a compromise is possible: you leave a random source alone and check the output not for exact value but just for "correctness" (e.g. that it has a specific format). But then you're not testing the logic that is responsible for the parts that you don't check (though you may not need to, see below).
• Единственный способ полностью протестировать функцию — тщательно перепробовать все возможные входные данные.
• Since this is almost always impossible, only a few "representative" ones are selected
  • And an assumption about the code is made that it handles all other possible inputs the same way
    • This is why test coverage metric is important: it will tell you when a code has changed in such a way that this assumption no longer holds

Чтобы выбрать оптимальный «репрезентативный» ввод, следуйте интерфейсу функции.

• Если во входных данных есть несколько диапазонов, которые вызывают различное поведение, значения края обычно являются наиболее полезными.
• Outputs are checked against the interface's promises
  • Sometimes, the interface doesn't promise a specific value for given inputs, variations are considered implementation details. Then you test not for a specific values but only what the interface guarantees.
    • Testing implementation details is only useful if other components rely on them -- then they are not really implementation details but parts of a separate, private interface.