2015-05-14 2 views
2

Один из коллег в моей команде говорит, что некоторые методы должны иметь как предварительные условия & постусловий. Но дело касается покрытия кода, эти условия не вызывались (не тестировались) до тех пор, пока не была реализована недействительная реализация (просто использовалась в модульном тесте). Давайте возьмем пример ниже.Постусловия и TDD

public interface ICalculator 
{ 
    int Calculate(int x, int y); 
} 


public int GetSummary(int x, int y) 
{ 
    // preconditions 

    var result = calculator.Calculate(x, y); 

    // postconditions 

    if (result < 0) 
    { 
     **throw new Exception("...");** 
    } 

    return result; 
} 

Два варианта для нас:

1/Удалить тест реализации + Постусловия

2/Keep оба тестовых реализаций + Постусловия

Можете ли вы дать несколько советов, пожалуйста?

ответ

4

Сохраняйте предварительные и последующие условия.

Здесь вам понадобятся как минимум четыре теста: комбинации (pre, post) x (pass, fail). Ваш неудачный постмодульный тест пройдет, если будет выбрано ожидаемое исключение.

Это легко сделать в JUnit с его аннотацией @Test(expected = Exception.class).

Будьте осторожны с коллегами, которые делают общие утверждения типа «X всегда должен быть правдой». Догмы во всех ее формах следует избегать. Поймите причины, чтобы делать вещи и делать их, когда они имеют смысл.

+0

Вы не имели в виду «Всегда избегайте догмы». ? ;-) –

+0

Я полагаю, что такие качества, как догма ..... d'oh! – duffymo

+0

Обнаружил, что в наших тестах возникла проблема, это вопрос насмешливой ссылочной службы (в этом примере - ICalculator). Также его можно издеваться, чтобы возвращать плохие результаты, чтобы нарушить постусловия, и удалил «недействительную реализацию, реализованную (только что использовавшуюся в модульном тесте)». – fred

1

Эти условия должны быть видны с точки зрения дизайна. Они обеспечивают калькулятор должен работать нормально, возвращая результат в диапазоне ожидаемых значений.

Вы должны увидеть код MS contracts project, чтобы взять документ там.