Czy powinno to być „Arrange-Assert-Act-Assert”?

Jeśli chodzi o klasyczny wzorzec testowy Arrange-Act-Assert , często dodaję kontr-twierdzenie, które poprzedza Act. W ten sposób wiem, że przemijające stwierdzenie naprawdę mija w wyniku działania.

Myślę o tym jako analogicznym do czerwonego w czerwono-zielonym-refaktorze, gdzie tylko wtedy, gdy widzę czerwony pasek podczas moich testów, wiem, że zielony pasek oznacza, że ​​napisałem kod, który robi różnicę. Jeśli napiszę pozytywny test, każdy kod go spełni; podobnie, w odniesieniu do Arrange-Assert-Act-Assert, jeśli moje pierwsze stwierdzenie nie powiedzie się, wiem, że jakakolwiek ustawa przeszłaby ostateczną weryfikację - tak, że w rzeczywistości nie weryfikowała niczego na temat ustawy.

Czy twoje testy są zgodne z tym schematem? Dlaczego lub dlaczego nie?

Zaktualizuj wyjaśnienie: początkowe stwierdzenie jest zasadniczo przeciwieństwem ostatecznego stwierdzenia. To nie jest twierdzenie, że Arrange zadziałało; to twierdzenie, że Act jeszcze nie zadziałał.

Nie jest to najczęstsza czynność, ale wciąż jest na tyle powszechna, że ​​ma własną nazwę. Ta technika nazywa się Guard Assertion . Możesz znaleźć szczegółowy opis tego na stronie 490 w doskonałej książce xUnit Test Patterns autorstwa Gerarda Meszarosa (wysoce zalecane).

Zwykle sam nie używam tego wzorca, ponieważ uważam, że bardziej poprawne jest napisanie konkretnego testu, który weryfikuje wszelkie warunki wstępne, które czuję potrzebę spełnienia. Taki test powinien zawsze kończyć się niepowodzeniem, jeśli warunek wstępny zawodzi, a to oznacza, że ​​nie potrzebuję go osadzonego we wszystkich innych testach. Daje to lepszą izolację obaw, ponieważ jeden przypadek testowy weryfikuje tylko jedną rzecz.

Może istnieć wiele warunków wstępnych, które muszą zostać spełnione dla danego przypadku testowego, więc możesz potrzebować więcej niż jednego potwierdzenia ochrony. Zamiast powtarzać je we wszystkich testach, posiadanie jednego (i tylko jednego) testu dla każdego warunku wstępnego sprawia, że ​​kod testu jest łatwiejszy w utrzymaniu, ponieważ w ten sposób będziesz mieć mniej powtórzeń.

Może to być również określona jako przyporządkowania Załóżmy -Act-Assert.

W NUnit istnieje techniczna obsługa tego, jak w przykładzie tutaj: http://nunit.org/index.php?p=theory&r=2.5.7

Oto przykład.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

Możliwe, że napisałem Range.includes() aby po prostu zwrócić prawdę. Nie zrobiłem tego, ale mogę sobie wyobrazić, że mogłem. Albo mogłem napisać to źle na wiele innych sposobów. Miałbym nadzieję i spodziewałbym się, że z TDD właściwie to zrobiłem - to includes()po prostu działa - ale może nie udało mi się. Zatem pierwsze stwierdzenie jest testem poczytalności, aby upewnić się, że drugie stwierdzenie jest naprawdę znaczące.

Przeczytaj sam, assertTrue(range.includes(7));mówi: „Zapewnij, że zmodyfikowany zakres obejmuje 7”. Czytane w kontekście pierwszego stwierdzenia, mówi ono: „potwierdź, że wywołanie metody encompass () powoduje uwzględnienie 7. A ponieważ encompass jest jednostką, którą testujemy, myślę, że ma to jakąś (małą) wartość.

Przyjmuję własną odpowiedź; wielu innych źle zinterpretowało moje pytanie jako dotyczące testowania konfiguracji. Myślę, że to jest nieco inne.

Arrange-Assert-Act-AssertTest można zawsze refactored do dwóch testów:

1. Arrange-Assert

i

2. Arrange-Act-Assert

Pierwszy test będzie dotyczył tylko tego, co zostało ustawione w fazie aranżacji, a drugi test będzie dotyczył tylko tego, co wydarzyło się w fazie działania.

Ma to tę zaletę, że daje bardziej precyzyjne informacje zwrotne na temat tego, czy faza aranżacji, czy aktu się nie powiodła, gdy była w oryginale Arrange-Assert-Act-Assert są one ze sobą powiązane i musiałbyś zgłębić i zbadać dokładnie, które asercja zawiodła i dlaczego zawiodła, aby wiedzieć, to był układ lub akt, który zawiódł.

Spełnia również cel testowania jednostkowego lepiej, ponieważ dzielisz test na mniejsze niezależne jednostki.

Na koniec pamiętaj, że za każdym razem, gdy zobaczysz podobne sekcje aranżacji w innym teście, powinieneś spróbować wyciągnąć je do wspólnych metod pomocniczych, aby testy były bardziej SUCHE i łatwiejsze do utrzymania w przyszłości.

Teraz to robię. AAAA innego rodzaju

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

Przykład testu aktualizacji:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

Powodem jest to, że ACT nie zawiera odczytu ReadUpdated, ponieważ nie jest on częścią aktu. Akt tylko zmienia i ratuje. Tak naprawdę, ARRANGE ReadUpdated dla potwierdzenia, wzywam ASSEMBLE w celu potwierdzenia. Ma to na celu uniknięcie pomyłki w sekcji ARRANGE

ASSERT powinien zawierać tylko potwierdzenia. To pozostawia ASSEMBLE między ACT i ASSERT, który tworzy asercję.

Wreszcie, jeśli nie uda ci się zorganizować, twoje testy nie są poprawne, ponieważ powinieneś mieć inne testy, aby zapobiec / znaleźć te trywialne błędy. Ponieważ dla scenariusza, który przedstawiam, powinny już istnieć inne testy sprawdzające ODCZYT i TWORZENIE. Jeśli utworzysz „Guard Assertion”, możesz łamać DRY i tworzyć konserwację.

Rzucanie asercji „kontroli poczytalności” w celu sprawdzenia stanu przed wykonaniem testowanej czynności jest starą techniką. Zwykle piszę je jako rusztowanie testowe, aby udowodnić sobie, że test robi to, czego oczekuję, i usuwam je później, aby uniknąć zaśmiecania testów rusztowaniem testowym. Czasami pozostawienie rusztowania na miejscu pomaga testowi służyć jako narracja.

Czytałem już o tej technice - być może przy okazji - od ciebie - ale jej nie używam; głównie dlatego, że jestem przyzwyczajony do formularza potrójnego A dla moich testów jednostkowych.

Teraz jestem ciekawy i mam kilka pytań: jak piszesz swój test, czy sprawiasz, że to twierdzenie zawodzi, po cyklu czerwony-zielony-czerwony-zielony-refaktor, czy też dodajesz je później?

Czy czasami zawodzisz, być może po refaktoryzacji kodu? Co ci to mówi? Może mógłbyś podzielić się przykładem, w którym to pomogło. Dzięki.

Robiłem to już wcześniej, badając test, który się nie powiódł.

Po mocnym drapaniu się w głowę stwierdziłem, że przyczyną jest nieprawidłowe działanie metod wywoływanych podczas „Arrange”. Niepowodzenie testu było mylące. Dodałem Assert po aranżacji. To spowodowało, że test zakończył się niepowodzeniem w miejscu, które uwydatniło rzeczywisty problem.

Myślę, że występuje tu również zapach kodu, jeśli część testu Arrange jest zbyt długa i skomplikowana.

Ogólnie bardzo lubię „Organizuj, działaj, zgłaszaj” i używam go jako osobistego standardu. Jednak jedyną rzeczą, o której mi nie przypomina, jest uporządkowanie tego, co zaaranżowałem, kiedy stwierdzenia zostaną wykonane. W większości przypadków nie powoduje to zbytniej irytacji, ponieważ większość rzeczy automatycznie znika poprzez zbieranie śmieci itp. Jeśli jednak ustanowiłeś połączenia z zasobami zewnętrznymi, prawdopodobnie będziesz chciał je zamknąć, gdy skończysz z twoimi twierdzeniami lub wielu z was ma serwer lub drogie zasoby, które gdzieś trzymają połączenia lub ważne zasoby, które powinien być w stanie przekazać komuś innemu. Jest to szczególnie ważne, jeśli jesteś jednym z tych programistów, którzy nie używają TearDown ani TestFixtureTearDowndo czyszczenia po jednym lub kilku testach. Oczywiście „Rozmieść, działaj, zgłoś” nie odpowiada za niepowodzenie w zamknięciu tego, co otwieram; Wspominam o tym „gotcha” tylko dlatego, że nie znalazłem jeszcze dobrego synonimu słowa „A-word” dla słowa „dispose” do polecenia! Jakieś sugestie?

Zapoznaj się z wpisem Wikipedii dotyczącym projektowania według umowy . Święta trójca Arrange-Act-Assert jest próbą zakodowania niektórych z tych samych koncepcji i dotyczy udowodnienia poprawności programu. Z artykułu:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

Istnieje kompromis między wysiłkiem włożonym w jego ustawienie a wartością dodaną. AAA to przydatne przypomnienie o wymaganych minimalnych krokach, ale nie powinno zniechęcać nikogo do tworzenia dodatkowych kroków.

Zależy od twojego środowiska / języka testowego, ale zazwyczaj jeśli coś w części aranżacji zawiedzie, zostanie zgłoszony wyjątek i test zakończy się niepowodzeniem, wyświetlając go zamiast uruchamiać część Act. Więc nie, zwykle nie używam drugiej części Assert.

Ponadto w przypadku, gdy twoja część aranżacji jest dość złożona i nie zawsze rzuca wyjątek, możesz rozważyć zawinięcie jej w jakąś metodę i napisanie własnego testu, aby mieć pewność, że się nie powiedzie (bez rzucanie wyjątku).

Nie używam tego wzorca, bo myślę, że robię coś takiego:

Arrange
Assert-Not
Act
Assert

Może to być bezcelowe, ponieważ przypuszczalnie wiesz, że część aranżacji działa poprawnie, co oznacza, że ​​wszystko, co znajduje się w części aranżacji, musi również zostać przetestowane lub być na tyle proste, aby nie wymagało testów.

Na przykładzie odpowiedzi:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

Jeśli naprawdę chcesz przetestować wszystko w przykładzie, wypróbuj więcej testów ... na przykład:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

Ponieważ w przeciwnym razie brakuje tak wielu możliwości błędu ... np. Po uwzględnieniu zakres obejmuje tylko 7, itd ... Istnieją również testy długości zakresu (aby upewnić się, że nie zawiera on również przypadkowej wartości), i kolejny zestaw testów w całości do próby objęcia 5 w zakresie ... czego byśmy się spodziewali - wyjątku w encompass, czy zakresu niezmienionego?

W każdym razie chodzi o to, że jeśli w akcie są jakieś założenia, które chcesz sprawdzić, poddaj je własnemu testowi, tak?

Używam:

1. Setup
2. Act
3. Assert 
4. Teardown

Ponieważ czysta konfiguracja jest bardzo ważna.