Следует ли вам модульно протестировать возвращаемое значение Hardcode Properties?

Question

Должны ли мы проверять значения, на которые мы уже знаем ответ?

Если значение достаточно важно, чтобы быть выделенным значением жесткого кода, то должно ли оно быть достаточно важным, чтобы изменить тест одновременно со значением? или это просто перебор?!

Answer 1

Если под «жестко закодированными свойствами» вы подразумеваете что-то вроде этого (в Java):

int getTheAnswer() {
    return 42;
}

Тогда вам нужно спросить себя: почему бы не сделать это константой? Например,

static final int THE_ANSWER = 42;

В таком случае вам не нужно проводить его юнит-тестирование.

Во всех остальных случаях вы должны рассмотреть модульное тестирование.

Answer 2

Если бы вы разрабатывали свой код с использованием TDD, тогда ваш модульный тест - это то, что создало бы свойство с жестким кодом в первую очередь.

Answer 3

Требуется больше контекста, чтобы ответить на ваш вопрос. Это просто зависит. Ваш метод getXXX вызывается из другого тестируемого метода? Если так, то это уже проверено. Если нет, что делает клиент? Должен ли метод вообще существовать?

Answer 4

Лично я не беспокоюсь о тестировании чего-либо декларативного.

Answer 5

Должны ли мы проверять значения, на которые мы уже знаем ответ?

Откуда ты это знаешь? Кто-то, возможно, изменил код, и теперь он возвращает что-то еще.

Если эти значения являются частью общедоступного API, их следует проверить.

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

 // good
 assertEquals( "Number", myClass.getType(1234));
 assertEquals( "Number", MyClass.TYPE_NUMBER);

 // not so good
 assertEquals( MyClass.TYPE_NUMBER, myClass.getType(1234)); 

Answer 6

Помимо очевидных моментов из других ответов:

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

Иногда вам нужно нужно жестко кодировать значения, т. Е. При реализации интерфейсов, запрашивающих тестирование возможностей, что-то вроде

interface IDecoder { // in C#
    bool SupportStreaming { get; }
}

Конечно, при реализации интерфейса IDecoder, описанного выше, вам придется жестко кодировать значение для свойства SupportStreaming.

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

Answer 7

Нет, но лучший вопрос: почему вы жестко кодируете значения? Я знаю, что иногда у вас есть общесистемные настройки конфигурации, которые редко (или никогда) меняются, но в идеале даже они должны быть настраиваемыми и поэтому должны быть проверены. Значения, которые НИКОГДА не изменятся, по-прежнему должны быть доступны через именованные константы. Если ваша система еще находится на ранней стадии разработки, возможно, вы еще не создали эти компоненты, поэтому не беспокойтесь о их тестировании - пока. ;)

Хмм Хорошо, я думаю, что исключения могут быть математическими или физическими константами.