Testy xUnit

Cześć, właśnie zacząłem bawić się xUnit i robić testy jednostkowe. Do tej pory używałem wbudowanego mechanizmu MS.
Wydaje mi się, że miesza mi się wykonywanie testów jednostkowych z testami integracyjnymi.

Mam taki przypadek: Klasa abstrakcyjna Serializer. Ma takie metody jak WriteInt, WriteString itd. Po niej dziedziczą różne klasy konkretne, dzięki czemu możliwa jest serializacja do binary, SQL, XML i czego dusza zapragnie. Chciałem sobie stworzyć test takiej serializacji.

Chcę przetestować, czy obiekt zwróci to, co zapisze. I teraz nie za bardzo wiem, co mam robić, bo mam wrażenie, że w testy jednostkowe chcę wrzucić integracyjne.
Mam coś takiego:

public class SerializerTests
{
    void Serializer_Bool_Write_NoThrow(Serializer s)
    {
        s.WriteBool("BoolValue", true);
    }

    bool Serializer_Bool_Read_NoThrow(Serializer s)
    {
        return s.ReadBool("BoolValue");
    }
    //i inne na takiej zasadzie

    [Fact]
    public void BinarySerializerTest_ReadWrite_OK()
    {
        BinarySerializer bs = new BinarySerializer();
        Serializer_Bool_NoThrow(bs);
        //i inne

       //i teraz odczyt
       bool b = Serializer_Bool_Read_NoThrow(bs);
       Assert(b);
    }    
}

Czy to są jeszcze testy jednostkowe, czy już integracyjne? Czy jej sens robić testy jednostkowe do takich klas? Czy w ogóle dobrze posługuje się xUnitem?

Popracuj nad nazewnictwem bo ciężko się to czyta. Najlepiej dla mnie sprawdza się reguła Given When Then. Czy Ty tutaj testujesz kilka modułów swojej aplikacji w teście ? Jeśli nie, to nie jest to test integracyjny. Test jednostkowy testuję pojedynczy kawałek kodu takich modułów.

Czyli jeśli testuję cały serializer, a nie tylko jego pojedyncze metody, to nadal jest test jednostkowy?
No dobra, to inne pytanie. Wszystko oczywiście w jednym module. Test undo / redo

Żeby go wykonać, muszę stworzyć jakiś dokument, w nim kilka itemów, porobić jakieś zmiany. Coś w stylu (dla ułatwienia załóżmy, że operacje undo redo są w dokumencie):

Document doc = new Document();
Item item = doc.CreateItem();
doc.Undo();
Assert(doc.Items == 0);

doc.Redo();
Assert(doc.Items == 1);

item.Name = "Siema";
doc.Undo();
Assert(item.Name == "");

doc.Redo();
Assert(item.Name == "Siema");

Czy to dalej jest test jednostkowy, czy już integracyjny? I jakie nazewnictwo byś zaproponował? Jakiś konkretny przykład.

nie, jezeli testujesz cala klase to jest nie jest to test jednostkowy

Jednostkowy to jest ze wywolujesz jedna metode. Testujesz ja na zasadzie

1. sprawdzasz czy metody interfejsow jakich tam uzywasz zostaly wywolane (czesto nie potrzebujesz tego). Ja uzywam do tego frameworka Moq, ale on nie moze mockowac zwyklych klas (tylko interfejsy i czasami jest problem jak z bibloteka Azure, ze nie da sie jej zmockowac za pomoca moq)
2. dajesz jakis input i oczekujesz konkretnego rezultatu.

I nie testuj nigdy jezyka czy frameworka ktorego uzywasz

Czyli jeśli testuję cały serializer, a nie tylko jego pojedyncze metody, to nadal jest test jednostkowy?

Co to znaczy testować cały serializer?

Jeśli stworzysz klasę testów np. BinarySerializerTests ,a w niej będziesz miał metody np. should_deserialize_bool_value_when_something , should_deserialize_complex_object_when_something. To ta klasa testująca testować będzie cały binarny serializer ale testy w niej będą jednostkowe. W testach jednostkowych testujesz jednostkowy przypadek użycia.

Czytam, czytam i nic nie rozumiem. Mam wrażenie, że wszyscy mówimy o innych rzeczach. Mam klasę BinarySerializer, która wewnętrznie używa memorystream. Chcę ją przetestować. Zapisać do niej dane i je odczytać. Ja to zrobić poprawnie?

Juhas napisał(a):

Czytam, czytam i nic nie rozumiem. Mam wrażenie, że wszyscy mówimy o innych rzeczach. Mam klasę BinarySerializer, która wewnętrznie używa memorystream. Chcę ją przetestować. Zapisać do niej dane i je odczytać. Ja to zrobić poprawnie?

Masz tam jakąś dodatkową logikę? Bo jeśli to tylko obudowanie memory stream to tak jak @fasadin napisał nie ma sensu testować klas frameworka.

No mam logikę. Ta klasa wygląda np. tak:

//w binarnym serializerze olewam nazwy pól
public void WriteString(string name, string value)
{
    int len = value.Length;
    byte[] b = BitConverter.GetBytes(len);
    stream.Write(b, 0, b.Length); //zapisuję długość stringa

    //pseudokod, bo nie pamiętam jak to robię
    byte[] sb = BitConverter.GetBytes(value);
    stream.Write(sb, 0, sb.Length); //zapisuję stringa 
}

No i analogicznie działa odczyt. Najpierw odczytuję ilość znaków ze stringa, tworzę bufor o odpowiedniej wielkości i odczytuję dane z memorystream.

Juhas napisał(a):

No mam logikę. Ta klasa wygląda np. tak:

Kopiuj

//w binarnym serializerze olewam nazwy pól
public void WriteString(string name, string value)
{
    int len = value.Length;
    byte[] b = BitConverter.GetBytes(len);
    stream.Write(b, 0, b.Length); //zapisuję długość stringa

    //pseudokod, bo nie pamiętam jak to robię
    byte[] sb = BitConverter.GetBytes(value);
    stream.Write(sb, 0, sb.Length); //zapisuję stringa 
}

No i analogicznie działa odczyt. Najpierw odczytuję ilość znaków ze stringa, tworzę bufor o odpowiedniej wielkości i odczytuję dane z memorystream.

No moim zdaniem nie ma sensu tego testować. Obudowałeś tutaj użycie Memory stream. Ale jeśli bardzo chcesz to wtedy testujesz metodę WriteString i tyle.

Będę kontynuował tutaj. Teraz rozumiem Twoją zagwozdkę, ale możesz przecież przy pomocy serializacji wygenerować sobie dane i zapisać je gdzieś. a potem przy teście deserializacji przekazać dane i oczekiwać jakiegoś wyniku ? Czyli dla danego załóżmy np. xml'a oczekujesz jakiegoś obiektu. W takim wypadku masz dwa oddzielne testy i oczekujesz dla specyficznych danych konkretnych wyników. Jeśli zmieni się implementacja i serializacji lub deserializacji i zwróci Ci coś innego niż oczekujesz to test nie przejdzie.

error91 napisał(a):

No moim zdaniem nie ma sensu tego testować. Obudowałeś tutaj użycie Memory stream. Ale jeśli bardzo chcesz to wtedy testujesz metodę WriteString i tyle.

Ale przecież używa też BitConverter i zapisuje te stringi w jakiejś istotnej kolejności. Chociaż faktycznie, wszystko to klasy frameworka... jeszcze trochę i dojdziemy do wniosku, że wszystkie testy w końcu testują tylko klasy frameworka. :P

@Juhas: no niestety z zapisem do strumienia czy dodawaniem do kolekcji jest ten problem, że nie da się tego zrobić bez odczytu. Można napisać dwa testy - jeden do write, który może sprawdzić jedynie czy zapis nie powoduje wyjątku oraz drugi do read, i w tym przypadku trzeba będzie najpierw zawołać write, no ale to będzie tylko setup testu.
I dopóki używasz MemoryStream, a nie FileStream czy NetworkStream to nie są testy integracyjne.

fasadin napisał(a):

1. sprawdzasz czy metody interfejsow jakich tam uzywasz zostaly wywolane (czesto nie potrzebujesz tego). Ja uzywam do tego frameworka Moq, ale on nie moze mockowac zwyklych klas (tylko interfejsy i czasami jest problem jak z bibloteka Azure, ze nie da sie jej zmockowac za pomoca moq)

Co to znaczy "mockować coś"? Czyli wszystko co mockuje jest mockiem i najlepszy do tego jest automock? " :D