TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
V tomto, již předposledním, dílu se podíváme na problematiku unit testů – k čemu nám jsou vůbec dobré a jak se používají.
Vytvoříme sadu automatizovaných testů pro ověření funkčnosti naší aplikace, abychom měli jistotu, že funguje tak, jak má, i bez toho, abychom aplikaci sami spouštěli a zkoušeli klikat na různé možnosti.
Proč používat unit testy?
Určitě každý, kdo se programování trochu věnuje, zažil podobnou situaci – večer pracujete na svém projektu, jdete spát a ráno máte hlavu plnou nápadů, které byste mohli implementovat. Je jedno, zda je to přidání nové vlastnosti, pročištění kódu nebo oprava bugu, v každém případě se musíte zamyslet nad tím, jestli vaše úprava nevyvolá dalších deset bugů. Při větším projektu může ale ruční testování provedených změn trvat klidně hodiny, proto existují unit testy, aby nám práci usnadnily.
ASP.NET MVC obsahuje jednoduchý způsob pro psaní unit testů, je ale nutné vlastnit Visual Studio 2008 Professional nebo vyšší verzi, anebo můžete použít unit testy třetích stran.
Projekt NerdDinner.Tests
Jistě si pamatujete vytváření projektu NerdDinner a nabídku, zda chceme navíc vytvořit i projekt s unit testy. Zvolili jsme ano a díky tomu se už rovnou můžeme vrhnout na unit testy.
Jako první věc vytvoříme test, který bude kontrolovat třídu Dinner. Za tímto účelem vytvoříme uvnitř projektu NerdDinner.Tests nový adresář „Models“, klikneme na něj pravým tlačítkem a zvolíme „Add New Test“. Z nabídky vyberere typ testu „Unit Test“ a pojmenujeme ho „DinnerTest.cs“.
Vygeneruje se nám trocha pomocného kódu, ale ten malinko promažeme. Upravte soubor DinnerTest.cs tak, aby vypadal následovně:
using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace NerdDinner.Tests.Models
{
[TestClass]
public class DinnerTest
{
public DinnerTest()
{
}
}
}Atribut [TestClass] označuje testovací třídu, jednotlivé testovací metody do ní můžeme přidat pomocí public metod označených atributem [TestMethod].
Níže vidíte dva první testy, které prověří funkčnost třídy Dinner. První z nich kontroluje validitu objektu Dinner, pokud při vytváření zadáme chybné údaje. Druhá testuje, zda je objekt Dinner skutečně validní, pokud zadáme správné hodnoty:
namespace NerdDinner.Tests.Models
{
[TestClass]
public class DinnerTest
{
[TestMethod]
public void Dinner_Should_Not_Be_Valid_When_Some_Properties_Incorrect()
{
// Vytvoření pokusného objektu
Dinner dinner = new Dinner()
{
Title = "Testovací název",
Country = "USA",
ContactPhone = "blbost" //chybně zadaný telefon
};
// Je validní?
bool isValid = dinner.IsValid;
// Rozhodnutí o výsledku testu
Assert.IsFalse(isValid);
}
[TestMethod]
public void Dinner_Should_Be_Valid_When_All_Properties_Correct()
{
// Vytvoření pokusného objektu
Dinner dinner = new Dinner
{
Title = "Testovací název",
Description = "Nějaký popis",
EventDate = DateTime.Now,
HostedBy = "Chrasty",
Address = "One Microsoft Way",
Country = "USA",
ContactPhone = "425-703-8072",
Latitude = 93,
Longitude = -92,
};
// Je validní?
bool isValid = dinner.IsValid;
// Rozhodnutí o výsledku testu
Assert.IsTrue(isValid);
}
}
}Všimněte si názvů testů – jsou dlouhé, těžko zapamatovatelné. Oproti normálnímu zdrojovému kódu je to v případě testů velmi vhodné, s názvy už dál nijak nepracujeme a takto alespoň jednoduše víme, k čemu daný test slouží.
A ještě jedna poznámka – testy by měly být co nejkratší a zaměřit se jen na jednu jedinou funkcionalitu, mnohem snáze se pak odhalují chyby. Raději mít 100 krátkých testů než 20 dlouhých.
Spouštění testů
Pro spuštění testů máme několik možností. Můžeme například spustit úplně všechny testy, i ty předdefinované (v menu Test > Run > All Tests in Solution). Anebo můžeme umístit kurzor do konkrétní testovací třídy a v menu zvolit Test > Run > Tests in Current Context.
My použijeme druhý způsob – umístíme kurzor někam do třídy DinnerTest a zvolíme odpovídající položky v menu. Dole v okně se objeví výsledky testů a oba by měly úspěšně projít (passed):
Jak vidíte, napsat si takový malý test není vůbec nic těžkého. Nešetřete jimi, nemusíte mít špatný pocit, pokud počet testů bude sahat až ke stovkám u větších projektů!
Unit testy pro třídu DinnersController
Teď si napíšeme pár testů, které ověří funkčnost DinnersControlleru. Do adresáře Controller v projektu NerdDinner.Tests vložíme nový test s názvem DinnersControllerTest.cs.
Na ukázku napíšeme dva testy. Oba budou ověřovat akční metodu Details. První z testů ověří, že je vrácen nějaký view, pokud požádáme o večeři. Druhá ověří, že se nám vrátí view NotFound, pokud požádáme o neexistující večeři:
using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NerdDinner.Controllers;
namespace NerdDinner.Tests.Controllers
{
[TestClass]
public class DinnersControllerTest
{
[TestMethod]
public void DetailsAction_Should_Return_View_For_ExistingDinner()
{
// Vytvoření pokusného objektu
var controller = new DinnersController();
// Úkon
var result = controller.Details(1) as ViewResult;
// Rozhodnutí o výsledku testu
Assert.IsNotNull(result, "Očekávané nějaké view");
}
[TestMethod]
public void DetailsAction_Should_Return_NotFoundView_For_BogusDinner()
{
// Vytvoření pokusného objektu
var controller = new DinnersController();
// Úkon
var result = controller.Details(999) as ViewResult;
// Rozhodnutí o výsledku testu
Assert.AreEqual("NotFound", result.ViewName);
}
}
}
Ale pozor, máme tu problém!
Pokud podrobně prozkoumáme chybové zprávy, zjistíme, že důvod, proč test neprošel, je ten, že naše třída DinnersRepository nebyla schopná se připojit k databázi. Naše aplikace totiž používá databázi uloženou v adresáři App_Data projektu NerdDinner, tudíž je relativní cesta k databázi z testového projektu neplatná.
Ano, mohli bychom tento problém vyřešit například nakopírováním databáze do testovacího projektu a pak do souboru App.config přidat odpovídající connection string. V praxi je tento postup ale krajně nevhodný, a to hned z několika důvodů:
- Výrazně se prodlužuje doba provádění unit testů. Pokud máte testů desítky až stovky, je každé zdržení nepříjemné, ideální je, aby se všechny testy provedly v rámci několika sekund.
- Cílem testů je, aby byly co nejméně závislé na ostatních, což je v případě reálně běžící databáze problém.
Proto se v následující kapitolce podíváme na návrhový vzor „dependency injection“ (přesný překlad netuším, je to tak známý návrhový vzor, že ho má i většina lidí u nás vžitý pod anglickým názvem).
Dependency injection
Momentálně je třída DinnersController silně závislá na třídě DinnerRepository. Vlastně vše, co v první třídě provádíme, využívá tu druhou.
Ale třída DinnerRepository potřebuje pro svou funkčnost připojení k databázi, které při unit testech není možné jednoduše zajistit.
Z tohoto důvodu existuje návrhový vzor dependency injection. Podle něj není instance repository třídy vytvořena přímo ve třídě, která ji používá, ale místo toho ji přidáme pomocí konstruktoru. Pokud je navíc repository třída definovaná jako rozhraní, získáme tím dostatek flexibility pro snadné vytvoření „falešné“ třídy, která bude simulovat data přijatá při připojení k databázi.
Jako první krok musíme vytvořit rozhraní z třídy DinnerRepository.
Rozhraní IDinnerRepository
Pokud máte Visual Studio Professional a vyšší, stačí pro vytvoření rozhraní z existující třídy jednoduše kliknout na název dané třídy (v našem případě do DinnerRepository) pravým tlačítkem a z kontextové nabídky zvolit Refactor > Extract Interface.
Po kliknutí na tlačítko OK nám Visual Studio vygeneruje takovéto rozhraní:
public interface IDinnerRepository
{
IQueryable<Dinner> FindAllDinners();
IQueryable<Dinner> FindUpcomingDinners();
Dinner GetDinner(int id);
IQueryable<Dinner> FindByLocation(float latitude, float longitude);
void Add(Dinner dinner);
void Delete(Dinner dinner);
void Save();
}Zároveň s tím bude třída DinnerRepository automaticky odvozená od našeho nového rozhraní.
To je pro tentokrát vše. V posledním dílu doděláme podporu pro unit testy.
