Per paskutines dvi savaites teko rašyti ypatingai daug modulių testų (angl. unit tests) ir net pavyko pasiekti „išsvajotą“ 100% kodo aprėptį (angl. code coverage). Iš to gimė mintis parašyti kelių straipsnių ciklą apie rekomendacijas rašant modulių testus.

Modulių testų rekomendacijos – įrankiai ir aplinkos paruošimas
Modulių testų rekomendacijos – 13 modulių testų rašymo taisyklių
Modulių testų rekomendacijos – modulių testas ar integracijų testas?

Praeitoje dalyje aš pateikiau 13 modulių testų rašymo taisyklių. Straipsnis sukėlė labai gerą diskusiją (ypatingai Facebooke) ir vėliau buvo atnaujintas atsižvelgiant į jūsų pastabas. Šioje dalyje išnagrinėsime skirtumus tarp modulių testų ir integracijų testų bei patarimus rašant pastaruosius.

Modulių ar integracijų testas?

Labai dažnai modulių testų naujokai painioja modulių testus su integracijų testais ir vadina juos vienu vardu – modulių testais. Tai paaiškinama tuo, kad integracijų testai rašomi naudojant modulių testų karkasus bei tas pačias pagalbines bibliotekas. Nepaisant šio fakto, labai svarbu suprasti ideologinį skirtumą tarp jų, nes integracijų testų rašymas bei vykdymas turi savų niuansų.

Tai kas gi yra integracijų testas? Tam, kad atskirti modulių testą nuo integracijų testo, sau aš sugalvojau tokį apibrėžimą: jeigu testas naudoja bet kokius išorinius resursus, pavyzdžiui, failų sistemą, duomenų bazę, Web servisą ir panašiai ar testuoja iš karto kelis sistemos lygius, pavyzdžiui, prieigą prie duomenų kartu su verslo logika – jis yra integracijų testas.

Integracijų testams taikytina dauguma modulių testų rašymo taisyklių apart kelių, žemiau išvardinti skirtumai tarp jų:

  1. Integracijų testų vykdymas gali būti ilgesnis nei modulių, todėl visada patartina juos atskirti į atskirą rinkinį (angl. assembly) arba kategoriją (kai kurie modulių testų karkasai turi galimybę operuoti testų kategorijomis)
  2. Integracijų testai gali testuoti tiek viena sistemos lygį (pavyzdžiui, verslo logiką), tiek iš karto kelis (pavyzdžiui, prieiga prie duomenų kartu su verslo logika)
  3. Integracijų testai turi mokėti paruošti visus testo vykdymui reikalingus duomenis bei grąžinti sistemą į pradinę būseną testui pasibaigus, tam geriausiai tinka try-finally struktūra

Aukščiau išvardintus skirtumus paaiškinsiu tokiu pavyzdžių (tikrinamas vienas sistemos lygis – prieiga prie duomenų):

[Test]
[Category("Integration")]
public void Given_Not_Existing_Directory_Path_New_Directory_Is_Successfully_Created_After_Calling_CreateDirectoryIfNotExists()
{
  // Arrange
  var exists = true;
  var dirPath = Path.GetTempPath();
  var fs = new FileSystem();

  try
  {
    // Act
    fs.CreateDirectoryIfNotExists(dirPath);

    // Assert
    var doesDirExist = Directory.Exists(dirPath);
    Assert.AreEqual(exists, doesDirExist);
  }
  finally
  {
    if(Directory.Exists(dirPath)
    {
      Directory.Delete(dirPath)
    }
  }
}

Atkreipkite dėmesį, kad testas po savęs grąžina sistemą į pradinę būseną, t.y. ištrina ką tik sukurtą katalogą ir tai daroma finally bloke.

Kitoje dalyje mes aptarsime kas yra kodo aprėptis ir koks aprėpties procentas yra rekomenduojamas.

Patiko (1)

Rodyk draugams