Làm cách nào để chạy các phương thức thử nghiệm theo thứ tự cụ thể trong JUnit4?

Tôi muốn thực hiện các phương thức thử nghiệm được chú thích theo @Testthứ tự cụ thể.

Ví dụ:

public class MyTest {
    @Test public void test1(){}
    @Test public void test2(){}
}

Tôi muốn đảm bảo chạy test1()trước test2()mỗi lần tôi chạy MyTest, nhưng tôi không thể tìm thấy chú thích như thế nào @Test(order=xx).

Tôi nghĩ đó là tính năng khá quan trọng đối với JUnit, nếu tác giả của JUnit không muốn tính năng đặt hàng , tại sao?

Tôi nghĩ đó là tính năng khá quan trọng đối với JUnit, nếu tác giả của JUnit không muốn tính năng đặt hàng, tại sao?

Tôi không chắc chắn có một cách rõ ràng để làm điều này với JUnit, theo hiểu biết của tôi, JUnit giả định rằng tất cả các bài kiểm tra có thể được thực hiện theo thứ tự tùy ý. Từ câu hỏi thường gặp:

Làm thế nào để tôi sử dụng một vật cố thử nghiệm?

(...) Thứ tự của các yêu cầu phương thức thử nghiệm không được đảm bảo , do đó testOneItemCollection () có thể được thực thi trước testEmptyCollection (). (...)

Tại sao nó như vậy? Chà, tôi tin rằng làm cho các bài kiểm tra phụ thuộc vào trật tự là một cách làm mà các tác giả không muốn quảng bá. Các thử nghiệm phải độc lập, chúng không nên được ghép nối và vi phạm điều này sẽ khiến mọi thứ khó bảo trì hơn, sẽ phá vỡ khả năng chạy thử nghiệm riêng lẻ (rõ ràng), v.v.

Điều đó đang được nói, nếu bạn thực sự muốn đi theo hướng này, hãy cân nhắc sử dụng TestNG vì nó hỗ trợ chạy các phương thức thử nghiệm theo bất kỳ thứ tự tùy ý nào (và những thứ như chỉ định rằng các phương thức phụ thuộc vào các nhóm phương thức). Cedric Beust giải thích cách thực hiện việc này theo thứ tự thực hiện các bài kiểm tra trong testng .

Nếu bạn thoát khỏi phiên bản Junit hiện có của mình và tải xuống JUnit 4.11 trở lên trong đường dẫn xây dựng, đoạn mã sau sẽ thực thi các phương thức kiểm tra theo thứ tự tên của chúng, được sắp xếp theo thứ tự tăng dần:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {

    @Test
    public void testAcreate() {
        System.out.println("first");
    }
    @Test
    public void testBupdate() {
        System.out.println("second");
    }
    @Test
    public void testCdelete() {
        System.out.println("third");
    }
}

Nếu đơn hàng là quan trọng, bạn nên tự đặt hàng.

@Test public void test1() { ... }
@Test public void test2() { test1(); ... }

Cụ thể, bạn nên liệt kê một số hoặc tất cả các hoán vị thứ tự có thể để kiểm tra, nếu cần thiết.

Ví dụ,

void test1(); 
void test2(); 
void test3(); 


@Test
public void testOrder1() { test1(); test3(); }

@Test(expected = Exception.class)
public void testOrder2() { test2(); test3(); test1(); }

@Test(expected = NullPointerException.class)
public void testOrder3() { test3(); test1(); test2(); }

Hoặc, một bài kiểm tra đầy đủ của tất cả các hoán vị:

@Test
public void testAllOrders() {
    for (Object[] sample: permute(1, 2, 3)) {
        for (Object index: sample) {
            switch (((Integer) index).intValue()) {
                case 1: test1(); break; 
                case 2: test2(); break; 
                case 3: test3(); break; 
            }
        }
    }
}

Đây permute()là một hàm đơn giản lặp lại tất cả các hoán vị có thể có trong Bộ sưu tập mảng.

Di chuyển sang TestNG có vẻ là cách tốt nhất, nhưng tôi thấy không có giải pháp rõ ràng nào ở đây cho jUnit. Đây là giải pháp / định dạng dễ đọc nhất mà tôi tìm thấy cho jUnit:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {
    @Test
    void stage1_prepareAndTest(){};

    @Test
    void stage2_checkSomething(){};

    @Test
    void stage2_checkSomethingElse(){};

    @Test
    void stage3_thisDependsOnStage2(){};

    @Test
    void callTimeDoesntMatter(){}
}

Điều này đảm bảo các phương thức của giai đoạn 2 được gọi sau các phương thức của giai đoạn 1 và trước các phương thức của giai đoạn 3.

Đây là một trong những vấn đề chính mà tôi gặp phải khi làm việc trên Junit và tôi đã đưa ra giải pháp sau đây phù hợp với tôi:

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;

public class OrderedRunner extends BlockJUnit4ClassRunner {

    public OrderedRunner(Class<?> clazz) throws InitializationError {
        super(clazz);
    }

    @Override
    protected List<FrameworkMethod> computeTestMethods() {
        List<FrameworkMethod> list = super.computeTestMethods();
        List<FrameworkMethod> copy = new ArrayList<FrameworkMethod>(list);
        Collections.sort(copy, new Comparator<FrameworkMethod>() {

            @Override
            public int compare(FrameworkMethod f1, FrameworkMethod f2) {
                Order o1 = f1.getAnnotation(Order.class);
                Order o2 = f2.getAnnotation(Order.class);

                if (o1 == null || o2 == null) {
                    return -1;
                }

                return o1.order() - o2.order();
            }
        });
        return copy;
    }
}

cũng tạo một giao diện như dưới đây:

 @Retention(RetentionPolicy.RUNTIME)


@Target({ ElementType.METHOD})

public @interface Order {
public int order();
}

Bây giờ giả sử bạn có lớp A nơi bạn đã viết một số trường hợp thử nghiệm như dưới đây:

(@runWith=OrderRunner.class)
Class A{
@Test
@Order(order = 1)

void method(){

//do something

}

}

Vì vậy, thực thi sẽ bắt đầu từ phương thức có tên "phương thức ()". Cảm ơn!

JUnit hiện cho phép các phương thức kiểm tra chạy thứ tự bằng cách sử dụng các chú thích lớp:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
@FixMethodOrder(MethodSorters.JVM)
@FixMethodOrder(MethodSorters.DEFAULT)

Theo phương pháp kiểm tra mặc định được chạy theo thứ tự bảng chữ cái. Vì vậy, để đặt thứ tự các phương thức cụ thể, bạn có thể đặt tên cho chúng như:

a_TestWorkUnit_WithCertainState_ShouldDoSthing b_TestWorkUnit_WithCertainState_ShouldDoSthing c_TestWorkUnit_WithCertainState_ShouldDoSthing

Bạn có thể tìm thấy các ví dụ ở đây .

Thay đổi (chưa được phát hành) https://github.com/junit-team/junit/pull/386 giới thiệu a @SortMethodsWith. https://github.com/junit-team/junit/pull/293 ít nhất có thể dự đoán thứ tự mà không cần điều đó (trong Java 7 có thể khá ngẫu nhiên).

Nhìn vào một báo cáo JUnit. JUnit đã được tổ chức theo gói. Mỗi gói có (hoặc có thể có) các lớp TestSuite, mỗi lớp lần lượt chạy nhiều TestCase. Mỗi TestCase có thể có nhiều phương thức thử nghiệm của biểu mẫu public void test*(), mỗi phương thức sẽ thực sự trở thành một thể hiện của lớp TestCase mà chúng thuộc về. Mỗi phương thức kiểm tra (ví dụ TestCase) có tên và tiêu chí đạt / không đạt.

Những gì quản lý của tôi yêu cầu là khái niệm về các mục TestStep riêng lẻ , mỗi mục báo cáo các tiêu chí đạt / không đạt của riêng chúng. Thất bại của bất kỳ bước kiểm tra nào không được ngăn cản việc thực hiện các bước kiểm tra tiếp theo.

Trước đây, các nhà phát triển thử nghiệm ở vị trí của tôi đã tổ chức các lớp TestCase thành các gói tương ứng với (các) phần của sản phẩm được thử nghiệm, tạo một lớp TestCase cho mỗi thử nghiệm và biến mỗi phương thức thử nghiệm thành một "bước" riêng biệt trong thử nghiệm, hoàn thành với tiêu chí đạt / không đạt của chính nó trong đầu ra JUnit. Mỗi TestCase là một "thử nghiệm" độc lập, nhưng các phương thức riêng lẻ hoặc "các bước" thử nghiệm trong TestCase, phải xảy ra theo một thứ tự cụ thể.

Các phương thức TestCase là các bước của TestCase và các nhà thiết kế thử nghiệm có một tiêu chí vượt qua / thất bại riêng biệt cho mỗi bước kiểm tra. Bây giờ các bước kiểm tra bị xáo trộn, và các bài kiểm tra (tất nhiên) không thành công.

Ví dụ:

Class testStateChanges extends TestCase

public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()

Mỗi phương pháp kiểm tra khẳng định và báo cáo các tiêu chí vượt qua / thất bại riêng. Thu gọn điều này thành "một phương pháp thử nghiệm lớn" vì mục đích đặt hàng sẽ làm mất tính chi tiết của tiêu chí đạt / không đạt của từng "bước" trong báo cáo tóm tắt của JUnit. ... và điều đó làm đảo lộn các nhà quản lý của tôi. Họ hiện đang yêu cầu một sự thay thế khác.

Bất cứ ai cũng có thể giải thích làm thế nào một JUnit với thứ tự phương pháp thử nghiệm được xáo trộn sẽ hỗ trợ các tiêu chí vượt qua / thất bại riêng biệt của từng bước kiểm tra tuần tự, như được minh họa ở trên và được quản lý của tôi yêu cầu?

Bất kể tài liệu nào, tôi thấy đây là một hồi quy nghiêm trọng trong khung JUnit đang gây khó khăn cho rất nhiều nhà phát triển thử nghiệm.

Cập nhật JUnit 5 (và ý kiến ​​của tôi)

Tôi nghĩ đó là tính năng khá quan trọng đối với JUnit, nếu tác giả của JUnit không muốn tính năng đặt hàng, tại sao?

Theo mặc định, các thư viện kiểm thử đơn vị không thử thực hiện các kiểm tra theo thứ tự xảy ra trong tệp nguồn.
JUnit 5 như JUnit 4 hoạt động theo cách đó. Tại sao ? Bởi vì nếu thứ tự có vấn đề, điều đó có nghĩa là một số thử nghiệm được ghép nối giữa chúng và đó là điều không mong muốn đối với các thử nghiệm đơn vị .
Vì vậy, @Nestedtính năng được giới thiệu bởi JUnit 5 tuân theo cách tiếp cận mặc định tương tự.

Nhưng đối với các thử nghiệm tích hợp, thứ tự của phương pháp thử nghiệm có thể quan trọng vì một phương thức thử nghiệm có thể thay đổi trạng thái của ứng dụng theo cách mà một phương pháp thử nghiệm khác mong đợi. Ví dụ: khi bạn viết bài kiểm tra tích hợp để xử lý kiểm tra tại cửa hàng điện tử, phương thức kiểm tra đầu tiên được thực hiện là đăng ký một khách hàng, cách thứ hai là thêm các mục vào giỏ hàng và cách cuối cùng là thực hiện kiểm tra. Nếu người chạy thử không tôn trọng thứ tự đó, kịch bản thử nghiệm bị sai sót và sẽ thất bại.
Vì vậy, trong JUnit 5 (từ phiên bản 5.4), bạn có khả năng thiết lập thứ tự thực hiện bằng cách chú thích lớp kiểm tra với @TestMethodOrder(OrderAnnotation.class)và bằng cách chỉ định thứ tự @Order(numericOrderValue)cho các phương thức mà thứ tự quan trọng.

Ví dụ :

@TestMethodOrder(OrderAnnotation.class) 
class FooTest {

    @Order(3)
    @Test
    void checkoutOrder() {
        System.out.println("checkoutOrder");
    }

    @Order(2)
    @Test
    void addItemsInBasket() {
        System.out.println("addItemsInBasket");
    }

    @Order(1)
    @Test
    void createUserAndLogin() {
        System.out.println("createUserAndLogin");
    }
}

Đầu ra:

tạoUserAndLogin

addItemsInBasket

kiểm tra

Nhân tiện, việc chỉ định có @TestMethodOrder(OrderAnnotation.class)vẻ như không cần thiết (ít nhất là trong phiên bản 5.4.0 tôi đã thử nghiệm).

Lưu ý bên lề
Về câu hỏi: JUnit 5 có phải là lựa chọn tốt nhất để viết các bài kiểm tra tích hợp không? Tôi không nghĩ rằng nó nên là công cụ đầu tiên để xem xét (Cucumber và co thường có thể mang lại giá trị và tính năng cụ thể hơn cho các thử nghiệm tích hợp) nhưng trong một số trường hợp thử nghiệm tích hợp, khung JUnit là đủ. Vì vậy, đó là một tin tốt rằng các tính năng tồn tại.

Không chắc chắn tôi đồng ý, Nếu tôi muốn kiểm tra 'Tải lên tệp' và sau đó kiểm tra 'Dữ liệu được chèn bởi Tải lên tệp' tại sao tôi không muốn các dữ liệu này độc lập với nhau? Hoàn toàn hợp lý Tôi nghĩ rằng có thể chạy chúng một cách riêng biệt thay vì có cả hai trong trường hợp thử nghiệm Goliath.

Những gì bạn muốn là hoàn toàn hợp lý khi các trường hợp thử nghiệm đang được chạy như một bộ.

Thật không may, không có thời gian để đưa ra một giải pháp hoàn chỉnh ngay bây giờ, nhưng hãy xem lớp:

org.junit.runners.Suite

Cho phép bạn gọi các trường hợp thử nghiệm (từ bất kỳ lớp thử nghiệm nào) theo một thứ tự cụ thể.

Chúng có thể được sử dụng để tạo các bài kiểm tra chức năng, tích hợp hoặc hệ thống.

Điều này khiến đơn vị của bạn kiểm tra vì chúng không có thứ tự cụ thể (như được khuyến nghị), cho dù bạn có chạy chúng như vậy hay không, và sau đó sử dụng lại các thử nghiệm như một phần của bức tranh lớn hơn.

Chúng tôi sử dụng lại / kế thừa cùng một mã cho các bài kiểm tra đơn vị, tích hợp và hệ thống, đôi khi được điều khiển dữ liệu, đôi khi được điều khiển theo cam kết và đôi khi chạy như một bộ.

Xem giải pháp của tôi ở đây: "Junit và java 7."

Trong bài viết này, tôi mô tả cách chạy thử nghiệm Junit theo thứ tự - "giống như trong mã nguồn của bạn". Các bài kiểm tra sẽ được chạy, theo thứ tự các phương thức kiểm tra của bạn xuất hiện trong tệp lớp.

http://intellijava.blogspot.com/2012/05/junit-and-java-7.html

Nhưng như Pascal Thivent đã nói, đây không phải là một thực hành tốt.

Với JUnit 5.4, bạn có thể chỉ định thứ tự:

@Test
@Order(2)
public void sendEmailTestGmail() throws MessagingException {

bạn chỉ cần chú thích lớp của bạn

@TestMethodOrder(OrderAnnotation.class)

https://junit.org/junit5/docs/cản/user-guide/#writer-tests-test-execut-order

Tôi đang sử dụng điều này trong dự án của tôi và nó hoạt động rất tốt!

Tôi đã đọc một vài câu trả lời và đồng ý rằng đây không phải là cách thực hành tốt nhất, nhưng cách dễ nhất để đặt hàng các bài kiểm tra của bạn - và cách mà JUnit chạy các bài kiểm tra theo mặc định là theo tên chữ cái tăng dần.

Vì vậy, chỉ cần đặt tên bài kiểm tra của bạn theo thứ tự chữ cái mà bạn muốn. Cũng lưu ý tên kiểm tra phải bắt đầu bằng kiểm tra từ. Chỉ cần coi chừng số

test12 sẽ chạy trước test2

vì thế:

testA_MyFirstTest testC_ThirdTest testB_ATestThatRunSecond

Vui lòng kiểm tra cái này: https://github.com/TransparentMarket/junit . Nó chạy thử nghiệm theo thứ tự chúng được chỉ định (được định nghĩa trong tệp lớp đã biên dịch). Ngoài ra, nó có tính năng bộ AllTests để chạy thử nghiệm được xác định bởi gói phụ trước. Sử dụng triển khai AllTests, người ta có thể mở rộng giải pháp trong việc lọc các thuộc tính (chúng tôi đã từng sử dụng các chú thích @Fast nhưng chúng chưa được công bố).

Đây là một phần mở rộng cho JUnit có thể tạo ra hành vi mong muốn: https://github.com/aafuks/aaf-junit

Tôi biết rằng điều này chống lại các tác giả của triết lý JUnit, nhưng khi sử dụng JUnit trong các môi trường không phải là thử nghiệm đơn vị nghiêm ngặt (như được thực hành trong Java) thì điều này có thể rất hữu ích.

Cuối cùng tôi đã nghĩ rằng các bài kiểm tra của mình không chạy theo thứ tự, nhưng sự thật là sự lộn xộn đã xảy ra trong các công việc không đồng bộ của tôi. Khi làm việc với đồng thời, bạn cũng cần thực hiện kiểm tra đồng thời giữa các bài kiểm tra của mình. Trong trường hợp của tôi, các công việc và bài kiểm tra chia sẻ một semaphore, vì vậy các bài kiểm tra tiếp theo sẽ treo cho đến khi công việc đang chạy giải phóng khóa.

Tôi biết điều này không hoàn toàn liên quan đến câu hỏi này, nhưng có lẽ có thể giúp nhắm mục tiêu vấn đề chính xác

bạn có thể sử dụng một trong những đoạn mã sau:

@FixMethodOrder(MethodSorters.JVM)OR `@FixMethodOrder(MethodSorters.DEFAULT)` OR `@FixMethodOrder(MethodSorters.NAME_ASCENDING)` before your test class like this:


@FixMethodOrder(MethodSorters.NAME_ASCENDING)


public class BookTest { ...}