BLOGas.lt
Sukurk savo BLOGą Kitas atsitiktinis BLOGas

Savaitės video – NoSQL

Parašė Sergejus | 2011-08-31 20:31

Tikriausiai pastebėjote, kad tam tikri Lietuvos .NET vartotojų grupės susitikimai ar kiti Microsoft bendruomenės renginiai buvo įrašomi, bet taip niekad ir nebuvo viešai paskelbti. Nuo šiandien pradedu juos vešinti pasitelkus „savaitės video“ formatą. Kiekvieną savaitę šiame tinklaraštyje talpinsiu po video.

Pradėsime nuo mano pristatymo iš NoSQL.

Rodyk draugams

Lietuvos .NET vartotojų grupės susitikimas

Parašė Sergejus | 2011-08-24 09:16

Lietuvos .NET vartotojų grupė grįžta po vasaros atostogų ir siūlo jums du įdomius pristatymus! Domantas Jovaišas aptars ASP.NET MVC 3 naujoves bei pasidalins tam tikrais tips & tricks. Romualdas Stonkus papasakos apie naują SQL Server 2011 (codename Denali) versiją ir susifokusuos ties naujovių programuotojams.

Susitikimai vyks rugpjūčio 29 Kaune Technopolyje ir rugpjūčio 30 Vilniuje Crowne Plaza.

18:00 - 19:00 - SQL Server 2011 naujovės programuotojams, Romualdas Stonkus, DtecNet

19:30 - 20:30 - ASP.NET MVC 3 naujovės ir tips & tricks, Domantas Jovaišas, DevBridge

21:00 - … Boulingas!

Registracija: Kaune ir Vilniuje

Iki susimatymo!

Rodyk draugams

Modulių testų rekomendacijos – kodo aprėptis

Parašė Sergejus | 2011-08-16 18:51

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?
Modulių testų rekomendacijos – kodo aprėptis

Praeitoje dalyje aš paaiškinau skirtumus tarp modulių testų ir integracijų testų bei išnagrinėjome integracijų testų rašymo taisykles. Šioje, paskutinėje, dalyje mes aptarsime svarbią testavimo metriką – kodo aprėptį.

Kas yra kodo aprėptis?

Kodo aprėptis nusako koks funkcionalumo procentas yra padengtas testais arba kitaip tariant, kokia kodo dalis yra vykdoma leidžiant testus. Natūraliai atrodo, kuo didesnis šis procentas, tuo labiau galima pasitikėti testais. Deja, praktikoje tai ne visada tiesa. Išnagrinėkime klasę StringHelper ir jos testą:

public static class StringHelper
{
  public static string Reverse(string input)
  {
    var arr = input.ToCharArray();
    Array.Reverse(arr);
    return new String(arr);
  }
}

[Test]
public void Given_Not_Empty_String_It_Is_Correctly_Reversed()
{
  // Arrange
  var text = "Test text";
  var reversedText = "txet tseT";

  // Act  
  var result = StringHelper.Reverse(text);

  // Assert
  Assert.AreEqual(reversedText, result);
}

Pateikto testo pilnai užtenka, kad pasiekti 100% StringHelper kodo aprėptį. 100%! Ar tai reiškia, kad mūsų kodas yra visiškai be klaidų? Nebūtinai! Nors testo metu techniškai ir vykdomas visas Reverse metodo kodas, mes nežinome kas įvyks, kai bus perduota null reikšmė. Ogi gausime NullReferenceException pačioje pirmoje Reverse eilutėje. Padarykime tokį tikrinimą:

public static class StringHelper
{
  public static string Reverse(string input)
  {
    if (input == null) throw ArgumentNullException("input");
    var arr = input.ToCharArray();
    Array.Reverse(arr);
    return new String(arr);
  }
}

Toks kodas yra teisingesnis, bet mes jau nebeturime 100% kodo aprėpties. Tam reikia antro testo:

[Test]
[ExpectedException(typeof(ArgumentNullException))]
public void Given_Null_Argument_Exception_Is_Thrown()
{
  // Arrange
  var nullArgument = null;

  // Act
  StringHelper.Reverse(nullArgument);
}

Ir vėl turime 100% aprėptį, ar dabar kodas neturi klaidų? Šį kartą nežinome, ar kodas gerai veiks tu tuščia eilute. Po kelių tokių iteracijų, aš pradėjau suprasti tikrąją testais grindžiamo programavimo (angl. Test Driven Development) naudą, bet čia visai kita tema…

Koks yra rekomenduojamas kodo aprėpties procentas?

Kaip visada, atsakymas į tokius klausimas yra – „priklauso“. Kuo daugiau jūsų metodas turi apsaugų nuo blogų reikšmių, tuo daugiau testų reikia pasiekti gerą kodo aprėptį. Aš prisilaikau tokios nykščio taisyklės – ne mažiau kaip 80%.

 

Štai tiek aš norėjau papasakoti apie savo patirtį dirbant su modulių bei integracijų testais. Kai pradedi rimtai rašyti testus, paaiškėja, kad tai yra kitoks programavimas, reikalaujantis naujų žinių ir kiek kitokio mąstymo.

Rodyk draugams

Modulių testų rekomendacijos – modulių ar integracijų testas?

Parašė Sergejus | 2011-08-07 22:11

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.

Rodyk draugams