Testowanie Kontrolerów

Cześć jak poprawnie testować ten kontroler ?

        private IUserService userService;
        private ICategoryService categoryService;
        private IPostService postService;

        public HomeController(IUserService _userService, ICategoryService _categoryService, IPostService _postService)
        {
            userService = _userService;
            categoryService = _categoryService;
            postService = _postService;
        }
        public ViewResult Index()
        {
            var list = categoryService.GetAllHomeCategory();

            return View(list);
        }

        public PartialViewResult NewsPosts(int CategoryId)
        {
            var list = postService.GetNewsPostsByCategoryId(CategoryId);
            return PartialView("_NewsPosts",list);
        }

Dobrze probuje pisząc ten test tak ?

        [Test]
        public void Return_Home_Index()
        {


            var mockCtx = new  Mock<ICategoryService>();
            mockCtx.Setup(m => m.GetAllHomeCategory()).Returns(new List<HomeCategoryViewModel>
            {
                new HomeCategoryViewModel() { CategoryId = 1, Name = "P1"},
                new HomeCategoryViewModel() { CategoryId = 2, Name = "P2"}
            });

           
            var controller = new HomeController(null,mockCtx.Object,null);
            var result = controller.Index() as ViewResult;
            var list = (List<HomeCategoryViewModel>)result.ViewData.Model;
            

            Assert.AreEqual(list[0].Name, "P1");
        }

Nie testować w ogóle.

Odnośnie Twojego unit testu. ja osobiście preferuję używać stałych aby uniknąć literówek. Idąc twoim tokiem:

        [Test]
        public void Return_Home_Index()
        {
            const string expectedName = "P1";

            var mockCtx = new  Mock<ICategoryService>();
            mockCtx.Setup(m => m.GetAllHomeCategory()).Returns(new List<HomeCategoryViewModel>
            {
                new HomeCategoryViewModel() { CategoryId = 1, Name = expectedName },
                new HomeCategoryViewModel() { CategoryId = 2, Name = "P2"}
            });

            var controller = new HomeController(null,mockCtx.Object,null);
            var result = controller.Index() as ViewResult;
            var list = (List<HomeCategoryViewModel>)result.ViewData.Model;

            Assert.AreEqual(list[0].Name, expectedName );
        }

Oczywiście Twoją asercje można by bardziej rozbudować tak aby porównać całą liste. Czy liczba rekordów się zgadza, kolejność, czy dokładnie ta sama lista się zwróciła.
Dodatkowo możesz sprawdzić czy methoda GetAllHomeCategory została wywołana dokładnie raz.

Oczywiście że logika jest taka prosta że koszt pisania unit testu jest większy niż sama implementacja. Dobrze mieć 100% pokrycia kodu (lub do tego dążyć). Wyrabiać sobie dobre zwyczaje. Ten kod to idealne zadanie dla Juniora aby porobił coś w produkcyjnym kodzie i przy okazji nauczył się pisania kodów jednostkowych.

Michał Warmuz napisał(a):

Cześć jak poprawnie testować ten kontroler ?

Najlepiej wcale. Po to w kontrolerach i widokach nie trzyma się logiki żeby nie trzeba było ich testować

teo215 napisał(a):

Oczywiście że logika jest taka prosta że koszt pisania unit testu jest większy niż sama implementacja. Dobrze mieć 100% pokrycia kodu (lub do tego dążyć).

Zazwyczaj 100% kodu oznacza, że został wygenerowany albo wymałpiony przez juniorów, i generalnie taka sytuacja jest gorsza niż 30% uczciwego pokrycia.

Wyrabiać sobie dobre zwyczaje. Ten kod to idealne zadanie dla Juniora aby porobił coś w produkcyjnym kodzie i przy okazji nauczył się pisania kodów jednostkowych.

Dążenie do 100%, a już tym bardziej pisanie bezsensownych testów, które właściwie sprawdzają tylko, czy framework mockujący i kompilator działają, to nie są dobre zwyczaje.
Żeby się nauczyć pisać testy, trzeba ich od początku używać do sensownych przypadków, czyli jakiegoś kodu wykonującego logikę na danych wejściowych i zwracających przewidywalne wyniki.

Tylko podsumowanie, bo wszystko zostało już powiedziane:

• w kontrolerach nie umieszczamy żadnej logiki
• kontrolery służą tylko do przekazania żądania dalej (do serwisu)
• w związku z powyższym nie testujemy kontrolerów
• nie dążymy do 100% pokrycia testami
• testujemy TYLKO SWÓJ kod
• w związku z powyższym, nie testujemy działania frameworka, czy jakiegoś thirdparta - to już zostało zrobione