2012-11-06 32 views
15

Chciałbym napisać test na IndexOutOfBoundsException. Należy pamiętać, że mamy się używać JUnit 3.Java: Testy wyjątków z Junit 3

Mój kod:

public boolean ajouter(int indice, T element) { 
    if (indice < 0 || indice > (maListe.size() - 1)) { 
     throw new IndexOutOfBoundsException(); 
    } else if (element != null && !maListe.contains(element)) { 
     maListe.set(indice, element); 
     return true; 
    } 
} 

Po kilku badań odkryłem, że można to zrobić z JUnit 4 stosując @Test(expected = IndexOutOfBoundsException.class) ale nie ma gdzie nie mogę znaleźć jak to zrobić w JUnit 3.

Jak mogę to przetestować przy użyciu JUnit 3?

Odpowiedz

14

Zasadniczo, musisz wywołać metodę i zawodzić, jeśli to nie rzucać prawą wyjątku - czy to rzuca coś innego:

try { 
    subject.ajouter(10, "foo"); 
    fail("Expected exception"); 
} catch (IndexOutOfBoundException expect) { 
    // We should get here. You may assert things about the exception, if you want. 
} 
2

Prostym rozwiązaniem jest dodanie catch spróbować unittest i niech test nie powiedzie, gdy wyjątek nie zostanie rzucony

public void testAjouterFail() { 
    try { 
    ajouter(-1,null); 
    JUnit.fail(); 
    catch (IndexOutOfBoundException()) { 
    //success 
    } 
} 
31

testowaniu wyjątków w JUnit 3 wykorzystuje ten wzór:

try { 
    ... code that should throw an exception ... 

    fail("Missing exception"); 
} catch(IndexOutOfBoundsException e) { 
    assertEquals("Expected message", e.getMessage()); // Optionally make sure you get the correct message, too 
} 

Numer fail() zapewnia błąd, jeśli kod nie zgłasza wyjątku.

Używam tego wzoru również w JUnit 4, ponieważ zazwyczaj chcę, aby poprawne wartości były widoczne w komunikacie wyjątku, a @Test nie może tego zrobić.

+1

W JUnit 4 można ustawić oczekiwany wyjątek w @ test, ale można również użyć [ExpectedExceptions] (http://kentbeck.github.com/junit/javadoc/4.10/org/junit/rules/ExpectedException.html), które są bardziej elastyczne i pozwalają sprawdzić wiadomość. – assylias

+0

Ah, nie wiedziałem o tej zasadzie. Dodano JUnit 4.7. –

1

W swojej metodzie badania, zadzwoń ajouter() wewnątrz try .. catch bloku, co daje wartość indice które powinny spowodować wyjątek zostać wyrzucony z

  • catch z klauzulą, że połowy IndexOutOfBoundsException: w tym przypadku powróć z twojej metody testowej, a tym samym wskaż podanie.
  • drugi catch klauzula, że ​​łapie Throwable: w takim przypadku ogłosić awarię (nazywają fail()), ponieważ źle rodzaju wyjątek
  • po try .. catch zadeklarować awarię (zadzwonić fail()), ponieważ bez wyjątku został rzucony.
2

Jedną rzeczą, jaką można zrobić, to użyć logiczną, aby uruchomić test do zakończenia, a następnie można użyć dochodzić do sprawdzania wyjątek:

boolean passed = false; 
try 
{ 
    //the line that throws exception 
    //i.e. illegal argument exception 
    //if user tries to set the property to null: 
    myObject.setProperty(null); 
} 
catch (IllegalArgumentException iaex) 
{ 
    passed = true; 
} 
assertTrue("The blah blah blah exception was not thrown as expected" 
       , passed); 

Za pomocą tego testu, test zostanie nigdy nie można wykonać i można sprawdzić, czy został zgłoszony określony typ wyjątku.

1

Wydłużenie @ rozwiązania Aarona z pewnym statycznym (import) cukru składniowej umożliwia pisanie:

expected(MyException.class, 
     new Testable() { 
      public void test() { 
      ... do thing that's supposed to throw MyException ... 
      } 
     }); 

Testable jest jak Runnable który wykorzystuje test() podpis rzucanie Throwable.

public class TestHelper { 
    public static void expected(Class<? extends Throwable> expectedClass, Testable testable) { 
     try { 
      testable.test(); 
      fail("Expected "+ expectedClass.getCanonicalName() +" not thrown."); 
     } catch (Throwable actual) { 
      assertEquals("Expected "+ expectedClass.getCanonicalName() +" to be thrown.", expectedClass, actual.getClass()); 
     } 
    } 

    interface Testable { 
     public void test() throws Throwable; 
    } 
} 

W razie potrzeby można dodać sprawdzanie komunikatu wyjątku.