MVC 3: Jak nauczyć się testować za pomocą NUnit, Ninject i Moq?

Jeśli używasz Ninject.MVC3 pakiet nuget, wtedy część artykułu, który podlinkowałeś, który powodował zamieszanie, nie będzie wymagana. Ten pakiet ma wszystko, czego potrzebujesz, aby rozpocząć wstrzykiwanie kontrolerów, co jest prawdopodobnie największym punktem bólu.

Po zainstalowaniu tego pakietu, utworzy on NinjectMVC3.plik cs w folderze App_Start, wewnątrz tej klasy znajduje się metoda RegisterServices. W tym miejscu należy utworzyć powiązania między interfejsami i implementacje

private static void RegisterServices(IKernel kernel)  
{  
  kernel.Bind<IRepository>().To<MyRepositoryImpl>();
  kernel.Bind<IWebData>().To<MyWebDAtaImpl>();
}        

Teraz w kontrolerze możesz użyć constructor injection.

public class HomeController : Controller {  
    private readonly IRepository _Repo;
    private readonly IWebData _WebData;

    public HomeController(IRepository repo, IWebData webData) {
      _Repo = repo;
      _WebData = webData;
    }
}

Jeśli jesteś po bardzo wysokim zasięgu testu, to w zasadzie za każdym razem, gdy jeden logiczny kawałek kodu (powiedzmy kontroler) musi rozmawiać z innym (powiedzmy baza danych), powinieneś utworzyć interfejs i implementację, dodać powiązanie definicji do RegisterService i dodać nowy argument konstruktora.

Dotyczy to nie tylko kontrolera, ale każdej klasy, więc w powyższym przykładzie jeśli Twoje repozytorium implementacja potrzebowała do czegoś instancji WebData, dodałbyś pole readonly i konstruktor do swojej implementacji repozytorium.

Następnie, jeśli chodzi o testowanie, to co chcesz zrobić, to dostarczyć wyśmiewaną wersję wszystkich wymaganych interfejsów, tak, że jedyną rzeczą, którą testujesz, jest kod w metodzie, dla której piszesz test. Więc w moim przykładzie powiedzmy, że IRepository ma

bool TryCreateUser(string username);

Który jest wywoływany metodą kontrolera

public ActionResult CreateUser(string username) {
    if (_Repo.TryCreateUser(username))
       return RedirectToAction("CreatedUser");
    else
       return RedirectToAction("Error");
}

What you are naprawdę próbuje przetestować tutaj jest to, że If I typy return, nie chcesz tworzyć repozytorium, które zwróci true lub false na podstawie specjalnych wartości, które podasz. Tu chcesz się kpić.

public void TestCreateUserSucceeds() {
    var repo = new Mock<IRepository>();
    repo.Setup(d=> d.TryCreateUser(It.IsAny<string>())).Returns(true);
    var controller = new HomeController(repo);
    var result = controller.CreateUser("test");
    Assert.IsNotNull(result);
    Assert.IsOfType<RedirectToActionResult>(result)
    Assert.AreEqual("CreatedUser", ((RedirectToActionResult)result).RouteData["Action"]);
}

^ to się nie skompiluje jak znam lepiej xUnit i nie pamiętam nazw właściwości na przekierowaniu z góry głowy.

Więc podsumowując, jeśli chcesz, aby jeden kawałek kodu rozmawiał z innym, Walnij interfejs pomiędzy. To wtedy pozwala na wyśmiewanie drugiego kawałka kodu, dzięki czemu podczas testowania pierwszego możesz kontrolować wyjście i mieć pewność, że testujesz tylko dany kod.
Myślę, że to właśnie ten punkt naprawdę sprawił, że Penny drop dla mnie z tym wszystkim, robisz to niekoniecznie dlatego, że Kod tego wymaga, ale dlatego, że testy tego wymagają.

Ostatnia rada specyficzna dla MVC, w każdej chwili musisz uzyskać dostęp do podstawowych obiektów web, HttpContext, HttpRequest itp. interfejs, jak również (jak IWebData w moim przykładzie) , ponieważ podczas gdy można mock te za pomocą klas podstawowych*, staje się bolesne bardzo szybko, ponieważ mają wiele wewnętrznych zależności, które również trzeba mock.
Również z Moq, Ustaw MockBehaviour na Strict podczas tworzenia mocks i powie ci, jeśli coś jest wywoływane, że nie podałeś mock dla.