JavaScript - Подзадачи модульного тестирования - PullRequest
Новая
       52

JavaScript - Подзадачи модульного тестирования

0 голосов
/ 16 октября 2018

Они говорят:

«Вы должны протестировать интерфейс, а не реализацию.»

Другими словами, вас должен интересовать конечный результат, а нес тем, как это делается ( тестирование черного ящика ).

Также сказано, что вы должны не тестировать частные функции , а толькооткрытый интерфейс, который выставлен.Но мой вопрос ...

Что вы делаете с общедоступным интерфейсом (например, функцией), который зависит от нескольких подзадач, которые являются частными?Как вам следует протестировать это?

Рассмотрим приведенную ниже функцию calculateDiscountedPrice. Давайте представим, что первая функция общедоступна (например, экспорт по умолчанию), а остальные 3 являются частными. 

// PUBLIC TOP-LEVEL FUNCTION
export default function calculateDiscountedPrice(price, discount) {
    const dollarsOff = getDollarsOff(price, discount);
    return round(price - dollarsOff);
}

// PRIVATE SUBTASK
function getDollarsOff(price, discount) {
    return price * discount;
}

// PRIVATE SUBTASK
function round(number, precision = 2) {
    return isInt(number) 
    ? number
    : number.toFixed(precision);
}

// PRIVATE SUBTASK
function isInt(number) {
    return number % 1 === 0;
}

Пример использования: 

console.log(calculateDiscountedPrice(100, 0.75)) // 25

Как выКак видите, calculateDiscountedPrice - это публичная функция, которую мы выставляем, поэтому мы должны протестировать ее.Но как насчет трех других подзадач?Почему бы нам не проверить это?Будут ли тесты, которые охватывают calculateDiscountedPrice, охватывать и другие три?

1 Ответ

0 голосов
/ 16 октября 2018

Вы правы в том, что вам не следует тестировать приватные функции отдельно.

Когда вы пишете тесты для общедоступного кода, вы должны учитывать как можно больше ветвлений в вашем коде - так что ваши тесты коснутся всехчастные функции.

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

Так что для этого конкретного примеравы можете написать тесты вроде:

  • передать price целому числу, например 10, чтобы пройти «отрицательный» результат вызова isInt (если быть точным - будет числорезультат 0)
  • передача price не целому числу, например 7.35, чтобы пройти "положительный" результат вызова isInt
  • pass zero discount
  • передать ненулевое значение discount
  • использовать комбинации предыдущих вариантов и т. Д.

Позвольте мне заметить, что если вы будете использовать TDD технику с самого начала, то cЗначит, вы, по сути, получили эти контрольные примеры.

Позвольте мне также предложить вам потратить несколько минут и прочитать эту статью Дяди Боба, известного профессионала в разработке программного обеспечения.

...