Я ищу несколько советов для модульного тестирования таким образом, чтобы в производственном коде не оставались «тестовые зацепки».
Допустим, у меня есть статический класс (модуль VB.NET) с именем MethodLogger, у которого есть метод «void WriteEntry (string Message)», который предназначен для записи вызывающего метода и сообщения в файл журнала на диске. Фактическая цель WriteEntry () может быть перенаправлена на ложную реализацию IMethodLogger для запуска модульных тестов, а для всех других случаев она должна вызывать реальную реализацию IMethodLogger.
Вот краткое изложение того, что я до сих пор делал, и мне нравится подход - но в некоторых быстрых тестах это вызывает некоторые вопросы и сомнения:
[InternalAttributesVisibleTo("MethodLogger.Tests")]
internal static class MethodLogger
{
public void WriteEntry(string message)
{
LogWriter.WriteEntry(message);
}
private IMethodLogger LogWriter
{
get;
set;
}
#if DEBUG
internal void SetLogWriter(IMethodLogger logger)
{
LogWriter = logger;
}
#endif
}
Вот мои конкретные вопросы:
Это тесно связывает юнит-тесты с работой против сборки DEBUG; когда я запускаю модульные тесты, хотя кажется, что он не перестраивает тестируемую сборку специально в DEBUG - возможно ли это сделать?
- Хотел бы я когда-нибудь запустить модульные тесты для не отладочной сборки? Сверху головы я вижу меньшую ценность - но будет ли это?
Могу ли я использовать собственный флаг прекомпилятора, такой как "TEST" вместо "DEBUG"? Как бы я сказал Visual Studio всегда перестраивать цель с этим флагом для тестирования, чтобы убедиться, что мои крючки / швы доступны?