TDD обрабатывает снаружи?

Question

Предположим, я создал следующий тест для моего примера блогового приложения:

[TestClass]
public class when_the_blog_controller_index_action_executes : BlogControllerTests
{
      //...

    [TestMethod]
    [TestCategory("BlogController")]
    public void it_should_pass_the_latest_blogentries_to_the_view()
    {
        blogs = new List<BlogEntry>() { new BlogEntry("title1", "b1"), new BlogEntry("title2", "b2"), new BlogEntry("title3", "b3") };
        blogServiceMock = new Mock<IBlogService>();

        blogServiceMock.Setup(s => s.GetLatestBlogEntries())
                       .Returns(blogs);

        var controller = new BlogController(blogServiceMock.Object);

        var model = ((ViewResult)controller.Index()).Model as IEnumerable<BlogEntry>;

        Assert.IsTrue(blogs.SequenceEqual(model));
        blogServiceMock.VerifyAll();
    }
}

После реализации BlogController у меня запущен тест:

public class BlogController : Controller
{
    IBlogService blogService;

    public BlogController(IBlogService blogService)
    {
        this.blogService = blogService;
    }

    public ActionResult Index()
    {
        var model = blogService.GetLatestBlogEntries();

        return View(model);
    }
}

Так каков следующий шаг? Должен ли я создать реализацию для IBlogService (с тестом) и после создания репозитория (с тестом)? Если бы у меня была такая служба, я бы ничего не проверял, потому что я просто издевался над хранилищем ...

public class BlogService : IBlogService
{
    IBlogRepository blogRepository;

    public BlogService(IBlogRepository blogRepository)
    {
        this.blogRepository = blogRepository;
    }

    public IEnumerable<BlogEntry> GetLatestBlogEntries()
    {
        return blogRepository.GetLatestBlogEntries();
    }
}

Answer 1

Следующим шагом является модульное тестирование написанной вами реализации BlogService. В этом тесте вы должны убедиться, что в проверяемом хранилище вызываются правильные методы. Если позже ваша служебная логика будет развиваться и у вас появятся некоторые методы, которые выполняют не только доступ к хранилищу CRUD, ваш тест станет более понятным.

Ваша текущая реализация этого сервиса просто делегирует вызовы в репозиторий, и это то, что вам следует тестировать модулем.

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

Answer 2

 > TDD Process Outside-In?

Я бы использовал как внешнюю (BDD), так и внутреннюю (TDD) комбинацию в двух вложенных циклах, как описано в Разработка на основе поведения с SpecFlow и WatiN

* writing a failing (outside-in) integration tests
    * writing a failing (inside out) unit test as part of the solution of the integration test
        * making the unittest pass
        * refactor
    * writing the next failing unit test as part of the integration test

    * unitl the integration test passes

* writing the next failing integration tests