Czy wywołanie innej metody z testowanej klasy w czase Arrange łamie zasadę Izolacji?

W metodzie testowej próbuję sprawdzić czy testowana metoda dekompresuje dane. Aby to sprawdzić, na początku wywołuję metodę z tej samej klasy, która najpierw kompresuje string. Czy to jest zły test jednostkowy?

[Fact]
        public void UnzipData_CalledWithByteArrayParameter_ReturnsString()
        {
            _serializationService.CallerName = "";
            string someString = _jsonExample;
            byte[] array = _serializationService.ZipData(someString); //kompresja

            string result = _serializationService.UnzipData(array);

            Assert.False(result.Length == 0);
            Assert.True(result.Length > array.Length);
        }

Oczywiście, że Łamiesz zasadę izolacji, gdyż wynik testu nie zależy tylko od metody testowanej. To mógłby być test integracyjny, a jeśli Chcesz unit test tej metody, to Skompresuj na boku jakiś.string, taką metodą jakiej Używasz i Wstaw go do testu.

byte[] array = _serializationService.ZipData(someString); //
string result = _serializationService.UnzipData(array);

Tym sposobem testujesz odwracalność operacji, a nie samą kompresję.

Miej tego świadomość.

A nawet nie to. Odwracalność operacji byś testował, gdybyś robił asercję, która sprawdza czy result jest taki sam jak someString. To jeszcze miałoby jakiś sens (chociaż wtedy kompresja byłaby jak czarna skrzynka, i nie sprawdziłbyś i tak, co ci dokładnie wypluwa ZipData).

Teraz natomiast sprawdzasz tylko, czy długość resulta jest większa od liczby elementów tablicy array, więc w sumie dość słabe to testowanie. Wystarczy, że funkcja UnzipData zwróci ci randomowy długi string i już przechodzi test, mimo, że kod nie będzie miał sensu.

lion137 napisał(a):

Oczywiście, że Łamiesz zasadę izolacji, gdyż wynik testu nie zależy tylko od metody testowanej. To mógłby być test integracyjny, a jeśli Chcesz unit test tej metody, to Skompresuj na boku jakiś.string, taką metodą jakiej Używasz i Wstaw go do testu.

A co, jeśli ZipData też ma swój test? Wtedy można by rzec, że też jest pod kontrolą testów.

Poza tym wykorzystałem w swoim teście byte[] zwracany po spakowaniu i wciąż UnzipData mi zwraca null :/ a konkretnie tak (może źle?)

byte[] array = new byte[] { 31, 139, 8, 0, 0, 0, 0, 0, 0, 11, 125, 206, 61, 11, 194, 48, 16, 6, 224, 255, 114, 171, 77, 185, 94, 62, 74, 179, 234, 234, 34, 221, 196, 33, 144, 27, 2, 53, 197, 38, 138, 80, 250, 223, 141, 90, 16, 151, 194, 45, 7, 247, 222, 243, 158, 103, 8, 79, 176, 77, 5, 251, 49, 102, 142, 249, 56, 122, 30, 192, 206, 16, 221, 149, 193, 194, 193, 69, 7, 21, 120, 151, 223, 27, 97, 99, 4, 106, 129, 166, 39, 178, 100, 202, 212, 168, 100, 139, 170, 219, 33, 189, 196, 245, 244, 196, 183, 59, 167, 204, 254, 47, 3, 203, 182, 125, 61, 218, 240, 166, 129, 35, 151, 63, 143, 144, 66, 78, 159, 110, 63, 93, 9, 236, 4, 233, 30, 181, 45, 5, 164, 172, 165, 54, 70, 181, 155, 250, 154, 41, 250, 229, 5, 222, 237, 15, 25, 239, 0, 0, 0 };
string result = _serializationService.UnzipData(array);

Ostatecznie udało mi się znaleźć sposób by wywołać testowaną metodę z przygotowanym wcześniej parametrem. Na tej stronie otrzymuję base64 string który następnie mogę konwertować na byte[] przy użyciu klasy Convert.FromBase64String:

            var base64String = "H4sIAAAAAAAA/4WOPwvCMBDFv0tWm3K9/CnNqquLdDMOgdwQqCmaKIL0uxu1irgUbjjevXfvt79bFm6WmaaybD3GTDFvR09DkcopuiOVzbKNi86y4vEuvxWERnNQHHSPaFCXqUGKFmS3AjQAX/uOThdKmfxfzrJpqj79uNR/HijS6+c1pJDTzPzLIzl0HFUPyhQkIWqhtJbtIs+ce/IcHmtZn30RAQAA";
            byte[] array = Convert.FromBase64String(base64String);

            string result = _serializationService.UnzipData(array);