«Цель» модульных тестов - к чему мне стремиться?

Question

Сегодня я написал серию тестов вокруг метода, который принимает входное значение и возвращает другой массив данных в зависимости от того, проходит ли значение какой-либо (внутренний) проверочный тест, т.е.* Метод в основном выполняет поиск в (жестко закодированной) таблице, которая хранится в частном порядке в myComponent.

Это чувствуется неправильно.Я эффективно проверял значения в частной справочной таблице.Должен ли я заботиться о значениях, передаваемых внутрь и наружу?Должен ли я проверять длину выходного массива, а не его содержимое?Или это правильно для проверки конкретных ответов с учетом некоторого входного значения?

Короче говоря, что должно быть за намерением за подобным модульным тестом?

Answer 1

Это ценно, так как теперь вы знаете, что функция возвращает то, что должна.

В будущем, если вы измените реализацию, вы можете быть уверены, что она по-прежнему будет делать то, что должнавсе тесты пройдены.

---

Как вы должны проверять такие вещи?От вас зависит, сколько тестов вы хотите выполнить, и какую выгоду вы получите от таких тестов.

Answer 2

Если контракт вашего метода таков, что он возвращает "Blah" для ввода 4, тогда да, вы должны это проверить!

Answer 3

Модульное тестирование должно проверять небольшой фрагмент кода, например, один объект или даже один метод, и должно искать пути, которые может сломать метод / класс. ИМХО, юнит-тест, который никогда не ломается, может и не существовать. ;)

Answer 4

Если это важно с точки зрения требований, вы должны проверить это. Если важно, чтобы значение четыре возвращало «Blah», тогда у вас есть действительный тест - но я бы также извлек число 4 в значимое имя переменной и передал его в валидатор. Поэтому, кто бы ни прочитал ваш тест, он поймет, почему вы проходите четвертое значение. Если вы тестируете какой-то алгоритм, попробуйте использовать такой инструмент, как Pex, чтобы сгенерировать вход для вас. Это также обеспечит правильную работу вашей логики в SUD (тестируемой системе).

Answer 5

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

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

Answer 6

Контракт для MyComponent.Validator(4) заключается в том, что он возвращает массив, первым элементом которого является true, тогда этот тест полезен.Тем не менее, это действительно зависит от того, насколько сложна логика этого метода.Одно из правил, которых я придерживаюсь, заключается в том, что, написав короткие простые методы, вы можете пропустить большую часть тестирования: если что-то настолько просто, что может быть проверено визуально, то часто не стоит тестировать.принимает двести действительных чисел и возвращает уникальный результат из внутреннего массива для каждого, я бы не стал писать двести тестов.Я бы написал тесты для значений конечных точек и пошел бы дальше.