Bagaimana cara menguji yang tidak terkecuali dilemparkan?


238

Saya tahu bahwa satu cara untuk melakukannya adalah:

@Test
public void foo(){
   try{
      //execute code that you expect not to throw Exceptions.
   }
   catch(Exception e){
      fail("Should not have thrown any exception");
   }
}

Apakah ada cara yang lebih bersih untuk melakukan ini. (Mungkin menggunakan Junit @Rule?)


10
Tes JUnit dinilai gagal jika melempar pengecualian selain dari ekspektasi yang diharapkan. Biasanya tidak ada pengecualian yang diharapkan.
Raedwald

Apakah tidak ada perbedaan antara kegagalan dan kesalahan di JUnit? Yang pertama berarti tes gagal, yang kedua berarti sesuatu yang tidak terduga terjadi.
Vituel

Jawaban:


198

Anda mendekati ini dengan cara yang salah. Cukup uji fungsionalitas Anda: jika ada pengecualian, pengujian akan gagal secara otomatis. Jika tidak ada pengecualian yang dilemparkan, semua pengujian Anda akan berubah menjadi hijau.

Saya perhatikan pertanyaan ini menarik minat dari waktu ke waktu jadi saya akan sedikit memperluas.

Latar belakang pengujian unit

Ketika Anda menguji unit, penting untuk menentukan sendiri apa yang Anda anggap sebagai unit kerja. Pada dasarnya: ekstraksi basis kode Anda yang mungkin atau mungkin tidak menyertakan beberapa metode atau kelas yang mewakili satu fungsi.

Atau, sebagaimana didefinisikan dalam Seni Pengujian Unit, Edisi ke-2 oleh Roy Osherove , halaman 11:

Sebuah tes unit adalah bagian otomatis kode yang memanggil unit kerja yang diuji, dan kemudian cek beberapa asumsi tentang hasil akhir tunggal unit tersebut. Tes unit hampir selalu ditulis menggunakan kerangka pengujian unit. Itu dapat ditulis dengan mudah dan berjalan dengan cepat. Ini dapat dipercaya, mudah dibaca, dan dipelihara. Ini konsisten dalam hasilnya selama kode produksi tidak berubah.

Apa yang penting untuk disadari adalah bahwa satu unit kerja biasanya bukan hanya satu metode tetapi pada tingkat yang paling dasar itu adalah satu metode dan setelah itu dienkapsulasi oleh unit kerja lain.

masukkan deskripsi gambar di sini

Idealnya Anda harus memiliki metode pengujian untuk setiap unit kerja yang terpisah sehingga Anda selalu dapat segera melihat di mana ada masalah. Dalam contoh ini ada metode dasar yang disebut getUserById()yang akan mengembalikan pengguna dan ada total 3 unit karya.

Unit kerja pertama harus menguji apakah pengguna yang valid dikembalikan dalam kasus input yang valid dan tidak valid.
Setiap pengecualian yang dilemparkan oleh sumber data harus ditangani di sini: jika tidak ada pengguna, harus ada tes yang menunjukkan bahwa pengecualian dilemparkan ketika pengguna tidak dapat ditemukan. Contohnya IllegalArgumentExceptionadalah yang tertangkap dengan @Test(expected = IllegalArgumentException.class)anotasi.

Setelah Anda menangani semua usecases untuk unit kerja dasar ini, Anda naik satu level. Di sini Anda melakukan hal yang persis sama, tetapi Anda hanya menangani pengecualian yang berasal dari tingkat tepat di bawah yang sekarang. Ini membuat kode pengujian Anda terstruktur dengan baik dan memungkinkan Anda dengan cepat menelusuri arsitektur untuk menemukan di mana kesalahan terjadi, alih-alih harus melompat ke semua tempat.

Menangani input yang valid dan salah tes

Pada titik ini harus jelas bagaimana kita akan menangani pengecualian ini. Ada 2 jenis input: input yang valid dan input yang salah (input tersebut valid dalam arti yang ketat, tetapi itu tidak benar).

Ketika Anda bekerja dengan input yang valid, Anda menetapkan harapan implisit bahwa tes apa pun yang Anda tulis, akan berhasil.

Seperti metode panggilan dapat terlihat seperti ini: existingUserById_ShouldReturn_UserObject. Jika metode ini gagal (misalnya: sebuah pengecualian dilemparkan) maka Anda tahu ada yang tidak beres dan Anda dapat mulai menggali.

Dengan menambahkan tes lain ( nonExistingUserById_ShouldThrow_IllegalArgumentException) yang menggunakan input yang salah dan mengharapkan pengecualian, Anda dapat melihat apakah metode Anda melakukan apa yang seharusnya dilakukan dengan input yang salah.

TL; DR

Anda mencoba melakukan dua hal dalam pengujian Anda: periksa input yang valid dan salah. Dengan memecah ini menjadi dua metode yang masing-masing melakukan satu hal, Anda akan memiliki tes yang lebih jelas dan gambaran yang jauh lebih baik tentang di mana kesalahan terjadi.

Dengan tetap mengingat unit kerja yang berlapis-lapis, Anda juga dapat mengurangi jumlah tes yang Anda butuhkan untuk lapisan yang lebih tinggi dalam hierarki karena Anda tidak harus memperhitungkan setiap hal yang mungkin salah di lapisan bawah: lapisan di bawah yang sekarang adalah jaminan virtual bahwa dependensi Anda berfungsi dan jika ada yang salah, itu ada di lapisan Anda saat ini (dengan asumsi lapisan yang lebih rendah tidak melakukan kesalahan sendiri).


2
Masalahnya adalah saya mencoba untuk TDD dan salah satu kolaborator yang saya gunakan adalah melempar pengecualian. Jadi saya perlu menguji fakta bahwa saya mengkonsumsi pengecualian yang dilemparkan oleh kolaborator
Ankit Dhingra

6
Apakah Anda mengatakan fungsionalitas Anda tergantung pada penanganan pengecualian? Itu bau kode: ada pengecualian untuk membiarkan Anda menangkap masalah secara elegan; mereka tidak digunakan untuk kontrol aliran. Jika Anda ingin menguji skenario di mana pengecualian harus dibuang maka Anda harus menggunakan expectedanotasi. Jika Anda ingin menguji skenario di mana kode Anda gagal dan Anda ingin melihat apakah kesalahannya ditangani dengan benar: gunakan expecteddan mungkin gunakan konfirmasi untuk menentukan apakah itu telah diselesaikan.
Jeroen Vannevel

Masalahnya adalah bahwa saya tidak dapat memulihkan dari pengecualian yang telah terjadi di kolaborator dan semua yang saya lakukan hanyalah mencatat masalah menggunakan log.debug ("Pesan kesalahan"). Jadi tidak ada efek samping yang terjadi sebagai bagian dari catch catch yang mungkin bisa saya nyatakan.
Ankit Dhingra

5
@ JoeroenVannevel sangat valid untuk menguji bahwa situasi kesalahan yang menyebabkan pengecualian untuk dibuang ditangani dengan benar.
Thorbjørn Ravn Andersen

1
@ dpk ya Anda bisa. Anda menambah throws IllegalArgumentExceptiontes Anda. Yang Anda inginkan pada akhirnya, adalah bahwa tes Anda menjadi merah jika ada pengecualian. Nah, coba tebak? Anda tidak perlu menulis fail(). Seperti @Jeroen Vannevel menulis: "jika pengecualian dilemparkan tes akan gagal secara otomatis."
Amedee Van Gasse

132

Saya menemukan ini karena aturan SonarQube "squid: S2699": "Tambahkan setidaknya satu pernyataan untuk kasus uji ini."

Saya menjalani tes sederhana yang satu-satunya tujuan adalah untuk melewati tanpa membuang pengecualian.

Pertimbangkan kode sederhana ini:

public class Printer {

    public static void printLine(final String line) {
        System.out.println(line);
    }
}

Penegasan seperti apa yang dapat ditambahkan untuk menguji metode ini? Tentu, Anda bisa mencoba-coba di sekitarnya, tetapi itu hanya kode mengasapi.

Solusinya datang dari JUnit sendiri.

Jika tidak ada pengecualian yang dilemparkan dan Anda ingin menggambarkan perilaku ini secara eksplisit, cukup tambahkan expectedseperti dalam contoh berikut:

@Test(expected = Test.None.class /* no exception expected */)
public void test_printLine() {
    Printer.printLine("line");
}

Test.None.class adalah nilai default untuk nilai yang diharapkan.


30
Saya pikir ini adalah jawaban terbaik. Jawaban yang diterima bagus, dan penulis benar untuk menunjukkan bau kode. Namun dia tidak benar-benar menjawab pertanyaan spesifik.
HellishHeat

4
Sangat menarik untuk dicatat bahwa nilai default untuk yang diharapkan adalah Tidak ada, jadi hanya menjelaskan metode dengan @Test akan dilakukan.
oziomajnr


41

JUnit 5 (Jupiter) menyediakan tiga fungsi untuk memeriksa tidak adanya / kehadiran pengecualian:

assertAll​()

Menyatakan bahwa semua yang disediakan executables
  tidak membuang pengecualian.

assertDoesNotThrow​()

Menyatakan bahwa eksekusi yang
  disediakan executable/ supplier
tidak menimbulkan pengecualian .

  Fungsi ini tersedia
  sejak JUnit 5.2.0 (29 April 2018).

assertThrows​()

Menyatakan bahwa eksekusi yang disediakan executable
melempar pengecualian expectedType
  dan mengembalikan pengecualian .

Contoh

package test.mycompany.myapp.mymodule;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class MyClassTest {

    @Test
    void when_string_has_been_constructed_then_myFunction_does_not_throw() {
        String myString = "this string has been constructed";
        assertAll(() -> MyClass.myFunction(myString));
    }

    @Test
    void when_string_has_been_constructed_then_myFunction_does_not_throw__junit_v520() {
        String myString = "this string has been constructed";
        assertDoesNotThrow(() -> MyClass.myFunction(myString));
    }

    @Test
    void when_string_is_null_then_myFunction_throws_IllegalArgumentException() {
        String myString = null;
        assertThrows(
            IllegalArgumentException.class,
            () -> MyClass.myFunction(myString));
    }

}

1
Ini jawaban terbaik sekarang. Jawaban lain sedang mendiskusikan versi lama JUnit
Tejesh Raut

29

Java 8 membuat ini jauh lebih mudah, dan Kotlin / Scala jadi dua kali lipat.

Kita dapat menulis kelas utilitas kecil

class MyAssertions{
  public static void assertDoesNotThrow(FailingRunnable action){
    try{
      action.run()
    }
    catch(Exception ex){
      throw new Error("expected action not to throw, but it did!", ex)
    }
  }
}

@FunctionalInterface interface FailingRunnable { void run() throws Exception }

dan kemudian kode Anda menjadi sederhana:

@Test
public void foo(){
  MyAssertions.assertDoesNotThrow(() -> {
    //execute code that you expect not to throw Exceptions.
  }
}

Jika Anda tidak memiliki akses ke Java-8, saya akan menggunakan fasilitas java lama yang menyakitkan: blok kode aribitrary dan komentar sederhana

//setup
Component component = new Component();

//act
configure(component);

//assert 
/*assert does not throw*/{
  component.doSomething();
}

Dan akhirnya, dengan kotlin, sebuah bahasa yang saya baru saja jatuh cinta:

fun (() -> Any?).shouldNotThrow() 
    = try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }

@Test fun `when foo happens should not throw`(){

  //...

  { /*code that shouldn't throw*/ }.shouldNotThrow()
}

Meskipun ada banyak ruang untuk bermain-main dengan persis bagaimana Anda ingin mengekspresikan ini, saya selalu penggemar pernyataan fasih .


Mengenai

Anda mendekati ini dengan cara yang salah. Cukup uji fungsionalitas Anda: jika ada pengecualian, pengujian akan gagal secara otomatis. Jika tidak ada pengecualian yang dilemparkan, semua pengujian Anda akan berubah menjadi hijau.

Ini pada prinsipnya benar tetapi kesimpulannya salah.

Java memungkinkan pengecualian untuk aliran kontrol. Ini dilakukan oleh runtime JRE sendiri dalam API seperti Double.parseDoublevia NumberFormatExceptiondan Paths.getvia a InvalidPathException.

Mengingat Anda telah menulis komponen yang memvalidasi string Number untuk Double.ParseDouble, mungkin menggunakan Regex, mungkin parser yang ditulis tangan, atau mungkin sesuatu yang menyematkan beberapa aturan domain lain yang membatasi rentang ganda untuk sesuatu yang spesifik, cara terbaik untuk menguji ini komponen? Saya pikir tes yang jelas akan menyatakan bahwa, ketika string yang dihasilkan diuraikan, tidak ada pengecualian yang dilemparkan. Saya akan menulis tes menggunakan salah satu di atas assertDoesNotThrowatau /*comment*/{code}blok. Sesuatu seperti

@Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
  //setup
  String input = "12.34E+26" //a string double with domain significance

  //act
  boolean isValid = component.validate(input)

  //assert -- using the library 'assertJ', my personal favourite 
  assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
  assertDoesNotThrow(() -> Double.parseDouble(input));
}

Saya juga mendorong Anda untuk membuat parameter tes ini saat inputmenggunakan Theoriesatau Parameterizedagar Anda dapat lebih mudah menggunakan kembali tes ini untuk input lain. Atau, jika Anda ingin menjadi eksotis, Anda bisa menggunakan alat generasi tes (dan ini ). TestNG memiliki dukungan yang lebih baik untuk pengujian parameter.

Apa yang menurut saya sangat tidak menyenangkan adalah rekomendasi untuk menggunakan @Test(expectedException=IllegalArgumentException.class), pengecualian ini sangat luas . Jika kode Anda berubah sedemikian rupa sehingga komponen di bawah konstruktor tes memiliki if(constructorArgument <= 0) throw IllegalArgumentException(), dan tes Anda memasok 0 untuk argumen itu karena nyaman - dan ini sangat umum, karena data uji menghasilkan yang baik adalah masalah yang sangat sulit--, maka tes Anda akan menjadi bilah hijau meskipun tidak menguji apa pun. Tes semacam itu lebih buruk daripada tidak berguna.


2
(mengenai penggunaan pengecualian yang diharapkan) Sejak JUnit 4.13, Anda dapat menggunakan Assert.assertThrowsuntuk memeriksa bahwa beberapa kode melempar pengecualian.
MageWind

22

Jika Anda kurang beruntung untuk menangkap semua kesalahan dalam kode Anda. Anda bisa melakukannya dengan bodoh

class DumpTest {
    Exception ex;
    @Test
    public void testWhatEver() {
        try {
            thisShouldThrowError();
        } catch (Exception e) {
            ex = e;
        }
        assertEquals(null,ex);
    }
}

1
Hanya saran kecil, Exception exharus = null;sebelum Anda bisa mengujinya.
Denees

4
Ini bukan solusi yang bagus. Jika metode yang seharusnya tidak membuang pengecualian benar-benar melempar, Anda tidak akan mendapatkan pesan kesalahan yang berguna. Panggil saja metode yang tidak boleh melempar pengecualian, dan uji itu mengembalikan nilai (atau efek samping, seperti mencatat pengecualian). Jika nanti tiba-tiba melempar pengecualian, tes akan gagal.
NamshubWriter

3
Atau cukup masukkan Assert.fail (), IMO yang lebih mudah dan lebih cantik.
isaac.hazan

Ya aku setuju denganmu. Satu cara lagi adalah menambahkan anotasi di atas metode @Test (diharapkan = InvalidRequestException.class)
Ben Tennyson

Kesalahan ejaan Anda membingungkan: thisShouldThroughError -> thisShouldThrowError .
Oscar Bravo


7

Meskipun pos ini sudah berusia 6 tahun sekarang, namun, banyak yang telah berubah di dunia Junit. Dengan Junit5, sekarang Anda dapat menggunakan

org.junit.jupiter.api.Assertions.assertDoesNotThrow()

Ex:

public void thisMethodDoesNotThrowException(){
   System.out.println("Hello There");
}

@Test
public void test_thisMethodDoesNotThrowException(){
  org.junit.jupiter.api.Assertions.assertDoesNotThrow(
      ()-> thisMethodDoesNotThrowException()
    );
}

Semoga ini akan membantu orang yang menggunakan Junit5 versi terbaru


Saya berharap ada cara untuk menentukan kelas pengecualian konkret di sini. Saya harus melakukan ini di dalam Awaitility's untilAsserted(ThrowingRunnable assertion). Sistem yang sedang diuji saat ini melempar pengecualian khusus pada ThrowingRunnable yang saya berikan, tetapi saya ingin memberikan waktu sampai berhenti melakukannya. Namun jika itu akan melemparkan pengecualian yang berbeda, saya ingin tes gagal secara instan.
Ubeogesh

1

Jika Anda ingin menguji apakah target pengujian Anda mengkonsumsi pengecualian. Biarkan saja tes sebagai (tiruan kolaborator menggunakan jMock2):

@Test
public void consumesAndLogsExceptions() throws Exception {

    context.checking(new Expectations() {
        {
            oneOf(collaborator).doSth();
            will(throwException(new NullPointerException()));
        }
    });

    target.doSth();
 }

Tes akan berlalu jika target Anda mengkonsumsi pengecualian yang dilemparkan, jika tidak pengujian akan gagal.

Jika Anda ingin menguji logika konsumsi pengecualian Anda, semuanya menjadi lebih kompleks. Saya sarankan mendelegasikan konsumsi ke kolaborator yang bisa diejek. Karena itu tesnya bisa:

@Test
public void consumesAndLogsExceptions() throws Exception {
    Exception e = new NullPointerException();
    context.checking(new Expectations() {
        {
            allowing(collaborator).doSth();
            will(throwException(e));

            oneOf(consumer).consume(e);
        }
    });

    target.doSth();
 }

Tapi kadang-kadang ini dirancang berlebihan jika Anda hanya ingin mencatatnya. Dalam hal ini, artikel ini ( http://java.dzone.com/articles/monitoring-declarative-transac , http://blog.novoj.net/2008/09/20/testing-aspect-pointcuts-is-there -an-easy-way / ) dapat membantu jika Anda bersikeras tdd dalam kasus ini.


1

Gunakan assertNull (...)

@Test
public void foo() {
    try {
        //execute code that you expect not to throw Exceptions.
    } catch (Exception e){
        assertNull(e);
    }
}

6
Saya akan mengatakan ini menyesatkan. Blok tangkap tidak pernah tercapai, jadi assertNulljuga tidak pernah dieksekusi. Namun pembaca cepat mendapat kesan bahwa pernyataan dibuat yang benar-benar memverifikasi kasus yang tidak melempar. Dengan kata lain: jika blok tangkap tercapai, pengecualian selalu non-nol - dengan demikian dapat diganti dengan sederhana fail.
Andreas

memang menyesatkan, ..... tapi tunggu, ... oh saya melihat ... assertNull(e)akan melaporkan tes gagal, seperti yang dinyatakan etidak dapat nulldi catchblok ... Mike ini hanya pemrograman aneh: - /. .. ya setidaknya gunakan fail()seperti kata Andreas
Julien

1

Anda dapat berharap bahwa pengecualian tidak dibuang dengan membuat aturan.

@Rule
public ExpectedException expectedException = ExpectedException.none();

ExpectedExceptions digunakan untuk menyatakan pengecualian yang dilemparkan. Kode yang Anda berikan hanya untuk menginisialisasi aturan sehingga Anda dapat menambahkan persyaratan Anda untuk pernyataan tersebut. Kode ini sendiri tidak menambah nilai sama sekali. Javadoc juga menyatakan ini: "/ ** * Mengembalikan {@linkplain aturan TestRule} yang mengharapkan tidak ada pengecualian untuk * dilempar (identik dengan perilaku tanpa aturan ini). * /" Jadi itu akan memiliki hasil yang sama persis seperti tanpanya .
Pim Hazebroek

Saya setuju dengan Anda, dan tidak akan menggunakannya seperti itu, tetapi dimungkinkan untuk menegaskan bahwa tidak ada pengecualian yang dilemparkan. Jika tes lulus harus ada cukup untuk mengatakan bahwa pengecualian belum dilemparkan, tetapi di sisi lain jika ada pertanyaan pasti ada kebutuhan untuk itu. Dan jarang tetapi kadang-kadang masih bagus untuk membuatnya terlihat. Bagaimana jika kode dan keadaan berubah dan kami tidak memiliki tes untuk kasus tepi tertentu?
LazerBanana

Saya ingin tahu bagaimana Anda akan menegaskannya dengan pengecualian yang diharapkan. Dan ya, jika persyaratan berubah dan Anda tidak memiliki tes untuk kasus tepi tertentu Anda kacau ;-) selalu mencakup semua kasus sudut.
Pim Hazebroek

maksud kamu apa? Anda tidak menegaskannya, Anda mengharapkannya. Dalam hal ini, Anda mengharapkan tidak terkecuali. Tidak yakin apa yang sedang Anda bicarakan.
LazerBanana

0

Ini mungkin bukan cara terbaik tetapi pasti memastikan bahwa pengecualian tidak dibuang dari blok kode yang sedang diuji.

import org.assertj.core.api.Assertions;
import org.junit.Test;

public class AssertionExample {

    @Test
    public void testNoException(){
        assertNoException();
    }    

    private void assertException(){
        Assertions.assertThatThrownBy(this::doNotThrowException).isInstanceOf(Exception.class);
    }

    private void assertNoException(){
        Assertions.assertThatThrownBy(() -> assertException()).isInstanceOf(AssertionError.class);
    }

    private void doNotThrowException(){
        //This method will never throw exception
    }
}

0

Anda dapat melakukannya dengan menggunakan @Rule dan kemudian memanggil metode reportMissingExceptionWithMessage seperti yang ditunjukkan di bawah ini: Ini adalah kode Scala.

masukkan deskripsi gambar di sini


1
private val? Bahasa apakah ini? Jelas bukan Java; p Dan tolong, jangan berikan kode sebagai tangkapan layar, itu tidak disambut.
Andremoniy

Saya melihat Anda telah menyebutkan bahwa ini adalah Scala, tetapi mengatakan bahwa hal itu dapat dengan mudah dilakukan di Jawa bukanlah argumen yang kuat, saya minta maaf
Andremoniy

Saya menghapus bagian yang mengganggu Anda. Saya akan mencoba mengganti gambar juga. Belum tahu bagaimana cara menambahkan kode ..
Crenguta S

-1

Berikut ini gagal tes untuk semua pengecualian, dicentang atau tidak dicentang:

@Test
public void testMyCode() {

    try {
        runMyTestCode();
    } catch (Throwable t) {
        throw new Error("fail!");
    }
}

-1

Anda dapat membuat segala jenis pernyataan Anda sendiri berdasarkan pernyataan dari junit:

static void assertDoesNotThrow(Executable executable) {
    assertDoesNotThrow(executable, "must not throw");
}
static void assertDoesNotThrow(Executable executable, String message) {
    try {
        executable.execute();
    } catch (Throwable err) {
        fail(message);
    }
}

Dan uji:

//the following will succeed
assertDoesNotThrow(()->methodMustNotThrow(1));
assertDoesNotThrow(()->methodMustNotThrow(1), "fail with specific message: facepalm");
//the following will fail
assertDoesNotThrow(()->methodMustNotThrow(2));
assertDoesNotThrow(()-> {throw new Exception("Hello world");}, "Fail: must not trow");

Secara umum, ada kemungkinan untuk langsung gagal ("bla bla bla") tes dalam skenario apa pun, di tempat mana pun masuk akal. Misalnya menggunakannya dalam blok coba / tangkap untuk gagal jika ada yang dilemparkan ke dalam test case:

try{methodMustNotThrow(1);}catch(Throwable e){fail("must not throw");}
//or
try{methodMustNotThrow(1);}catch(Throwable e){Assertions.fail("must not throw");}

Ini adalah contoh dari metode yang kami uji, seandainya kami memiliki metode yang tidak boleh gagal dalam keadaan tertentu, tetapi bisa gagal:

void methodMustNotThrow(int x) throws Exception{
    if (x == 1) return;
    throw new Exception();
}

Metode di atas adalah sampel sederhana. Tetapi ini bekerja untuk situasi yang kompleks, di mana kegagalannya tidak begitu jelas. Ada impor:

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;
import static org.junit.jupiter.api.Assertions.*;

Ada opsi yang lebih baik untuk memeriksa bahwa pernyataan belum dilontarkan yang tidak melibatkan pembuatan kode kustom. @Rule adalah salah satunya
Vargan

@ Vargan Saya telah menunjuk metode untuk membuat pernyataan Anda sendiri seperti itu Dirancang Oleh JUnit terutama untuk tujuan membuat pernyataan Anda sendiri. JUnit menyatakan bahwa dengan desain, terutama untuk tujuan itu, untuk membuat aturan Anda sendiri, perluas perilaku JUnit dengan pernyataan yang belum diterapkan. Karena tidak semuanya diterapkan di dunia ini. Pernyataan ini bekerja secara identik sebagai pernyataan JUnit bekerja dalam hal melintas atau gagal serta melaporkan kegagalan.
armagedescu
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.