2010-10-27 2 views
11

Рассмотрим:Как написать единичный тест для «T должен быть ссылочным типом»?

class MyClass<T> where T : class 
{ 
} 

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

В идеале я должен иметь единичный тест, который проверяет эту спецификацию. Тем не менее, этот тест блок явно не будет работать, но это объясняет то, что я пытаюсь выполнить:

[Test] 
[DoesNotCompile()] 
public void T_must_be_a_reference_type() 
{ 
    var test = new MyClass<int>(); 
} 

Что я могу сделать, чтобы проверить спецификацию, которая реализована, не позволяя код для компиляции?

EDIT:

Подробнее: Итак, мое рассуждение для этого (ха-ха) является то, что я по методологии TDD, в которой вы не можете писать любой код, если у Вас нет неудачный единичный тест. Допустим, у вас было это:

class MyClass<T> { } 

Какой тест вы можете написать, если бы не T-класс? Что-то вроде default(T) == null?

Далее EDIT:

Таким образом, после «анализа первопричин» на это, проблема в том, что я полагался на default(T) будучи null в потребителя этого класса, в неявном виде. Я смог реорганизовать этот потребительский код в другой класс и указать там ограничение общего типа (ограничение его на class), что фактически делает этот код не скомпилированным, если кто-то должен был удалить ограничение на класс, о котором я говорю выше.

+3

Почему вы не тестируете модуль, что класс называется MyClass? – SLaks

+0

@SLaks: технически var test = new MyClass (); испытал бы это, не так ли? –

+0

Я думаю, что @SLaks использовал сарказм, чтобы доказать, что вам не нужно тестировать компилятор ... это работа Microsoft. – TheCloudlessSky

ответ

25

Зачем вам нужен единичный тест? Как вы написать модульный тест для метода, такого как

public void Foo(string x) 

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

EDIT: Просто быть немного менее причудливым: в этом случае спецификация подтверждается заявлением . Тесты должны, как правило, проверять поведение . Это одна из вещей, которые мне нравятся в кодовых контрактах: я не чувствую никакой потребности в модульном тестировании контрактов, если они не выражают что-то сложное - в этом случае это сложность, которую я бы тестировал, а не бит «контракты принудительно» ,

EDIT: Для того, чтобы ответить на вопрос редактирования:

Что тест вы можете написать, что потерпит неудачу, если T не были классом?

You мог написать что-то вроде:

Type definition = typeof(MyClass<>); 
Assert.Throws<ArgumentException>(() => definition.MakeGenericType(typeof(int))); 

Однако, это, кажется, идет вразрез с реальной целью тестирования ...

+0

Ну, я пытаюсь, чтобы мои модульные тесты включали все спецификации для тестируемого устройства. –

+0

@Jon Funny, мы подумали о том же примере –

+2

@Scott Whitlock - Но просто, что компиляция кода ** является ** вашим тестом. –

9

Не следует проверять, работает ли компилятор. Если вы укажете это в коде, этого достаточно. С точки зрения кода это примерно то же самое:

[Test] 
public void Test_whether_add_works() 
{ 
    int i = 1 + 2; 

    Assert.AreEqual(3, i); 
} 
+4

'[Test] public void Running1984() {Assert.AreEqual (5, 2 + 2); } ' –

+0

Hihi, Radiohead. –

2

Вы пишете правильный единичный тест? Похоже, что вы собираетесь тестировать компилятор C#, но не ваш код.

3

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

Подробнее о дихотомии типов и тестов см. В этой замечательной статье by Chris Smith, http://web.archive.org/web/20080822101209/http://www.pphsg.org/cdsmith/types.html

Смежные вопросы