тестирование внутреннего класса
У меня были проблемы с миграциями, я решил их, выполнив другой код в зависимости от того, связан текущий процесс с миграцией или нет, как вы можете видеть в этом вопросе .
В вашем случае вы могли бы сделать что-то вроде этого:
class ExceptionMapping(models.Model):
import sys
if 'makemigrations' not in sys.argv and 'migrate' not in sys.argv:
machine_id = models.IntegerField(null=True, blank=True, choices=MachineChoices())
else:
machine_id = models.IntegerField(null=True, blank=True)
Я согласен, что это решение немного хакерское, но оно работает.
5 ответов
Вы тесты записи, которые указывают поведение внешнего интерфейса класса верхнего уровня. Использует ли тот класс внутренние классы для реализации того поведения или нет, является деталью реализации класса, и тесты ничего не должны знать об этом.
Если внутренний класс не может быть соответственно протестирован через интерфейс класса верхнего уровня, то обычно лучше выгнать внутренний класс с квартиры и протестировать его непосредственно как новый класс верхнего уровня. Желание протестировать внутренние классы является запахом кода, что внутренний класс мог бы быть достаточно значительным, чтобы быть классом верхнего уровня.
Вы не тестируете его непосредственно. Это будет протестировано через класс, где это определяется.
И, если Вы применяете TDD как этот вопрос, который в настоящее время подразумевают теги, каков тест, Вы просто пишете, что призывают к внутреннему классу? Я имею в виду разве, что это не может быть стандартный класс, частный классом, Вы продолжаете работать?
При использовании Visual Studio MS для Модульных тестов необходимо просто создать частное Средство доступа. Внутренне это работает с отражениями, я думаю. Просто смотрите на сгенерированный код.
Не то, чтобы я рекомендовал бы это, но можно также использовать InternalsVisibleToAttribute.
Мы использовали класс помощника, который использует отражение, чтобы загрузить и назвать методы на внутренних классах. Также возможно изменить доступность во время компиляции с помощью Отладочного символа, например,
#if DEBUG
public
#else
internal
#endif
class MyInternalClass
{
...
}
Однако ответ Esko Luontola более корректен, поскольку это - требования к функциональности или бизнес-требования, которые являются самыми важными. Легко быть слишком сфокусированным на покрытии кода вместо того, чтобы тестировать важные области риска.