Нужны идеи для подхода TDD

Question

Мы только что выпустили переписанный (в третий раз) модуль для нашей проприетарной системы. Этот модуль, который мы называем Load Manager, на сегодняшний день является самым сложным из всех модулей нашей системы. Мы пытаемся получить исчерпывающий набор тестов, потому что каждый раз, когда мы делаем какие-либо существенные изменения в этом модуле, есть ад, который может заплатить неделями при сортировке ошибок и причуд. Однако разработка набора тестов оказалась довольно сложной, поэтому мы ищем идеи.

Гитары Load Manager находятся в классе LoadManagerHandler, это по существу все логические схемы модуля. Этот обработчик требует, чтобы несколько контроллеров выполняли методы CRUD в базе данных. Эти контроллеры, по сути, являются верхним слоем DAL, который находится сверху и абстрагирует наш код, сгенерированный LLBLGen.

Так что достаточно просто издеваться над этими контроллерами, которые мы используем с использованием фрейма Moq. Однако проблема связана с сложностью диспетчера загрузки, и проблемы, которые мы получаем, касаются не простых случаев, а случаев, когда в обработчике имеется значительный объем данных.

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

jobDetailControllerMock.Setup(mock => mock.GetById(1)).Returns(jobDetail1); 
jobDetailControllerMock.Setup(mock => mock.GetById(2)).Returns(jobDetail2); 
jobDetailControllerMock.Setup(mock => mock.GetById(3)).Returns(jobDetail3); 

Независимо от того, что я посылаю jobDetailController.GetById (х) я всегда вернусь jobDetail3. Это делает тестирование почти невозможным, потому что мы должны убедиться, что при внесении изменений все точки затронуты, что должно быть затронуто.

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

TL/DR: Я по существу ищу стратегии тестирования для ориентированного на данные кода, который является довольно сложным по своей природе.

Answer 1

Чтобы обойти "последних фиктивных побед" с Moq, вы могли бы использовать технику из этого блога:

Moq Triqs - Successive Expectations

EDIT:

На самом деле вы даже не нужно, что , На основе вашего примера Moq вернет разные значения на основе аргумента метода.

public interface IController { string GetById(int id); }

class Program 
{ 
    static void Main(string[] args) 
    { 
     var mockController = new Mock<IController>(); 

     mockController.Setup(x => x.GetById(1)).Returns("one"); 
     mockController.Setup(x => x.GetById(2)).Returns("two"); 
     mockController.Setup(x => x.GetById(3)).Returns("three"); 

     IController controller = mockController.Object; 

     Console.WriteLine(controller.GetById(1)); 
     Console.WriteLine(controller.GetById(3)); 
     Console.WriteLine(controller.GetById(2)); 
     Console.WriteLine(controller.GetById(3)); 
     Console.WriteLine(controller.GetById(99) == null); 
    } 
} 

Выход:

 
    one 
    three 
    two 
    three 
    True 

Answer 2

Я никогда не пользовался Moq, но кажется, что он должен быть в состоянии соответствовать притворному вызову по аргументам (-ам).

Беглый взгляд на Quick Start documentation имеет следующий отрывок:

//Matching Arguments 

// any value 
mock.Setup(foo => foo.Execute(It.IsAny<string>())).Returns(true); 


// matching Func<int>, lazy evaluated 
mock.Setup(foo => foo.Add(It.Is<int>(i => i % 2 == 0))).Returns(true); 


// matching ranges 
mock.Setup(foo => foo.Add(It.IsInRange<int>(0, 10, Range.Inclusive))).Returns(true); 

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

Answer 3

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

Answer 4

Независимо от того, что я посылаю jobDetailController.GetById (х) я всегда вернусь jobDetail3

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

Если вы хотите совершать повторные вызовы с одними и теми же входами, но с разными выходами, вы также можете использовать другую фальшивую фреймворк. RhinoMocks поддерживает идиому записи/воспроизведения. Вы правы, это не всегда то, что вы хотите, чтобы обеспечить порядок вызова. Я предпочитаю самого Мока за его простоту.

Answer 5

Как отметил Себа, вы действительно можете использовать согласование диапазон:

controller.Setup(x => x.GetById(It.IsInRange<int>(1, 3, Range.Inclusive))))).Returns<int>(i => jobs[i]); 

Этот код использует аргумент, передаваемый методу расчета, какое значение для возврата.

Answer 6

Похоже, что LoaderManagerHandler делает ... совсем немного работы. «Менеджер» в имени класса всегда меня несколько беспокоит ... с точки зрения TDD, возможно, стоит подумать о том, чтобы сломать класс соответствующим образом, если это возможно.

Как долго этот класс?