8
Ví dụ:Ý tưởng tồi là tạo các xét nghiệm dựa vào nhau trong một trận thi đấu?
// NUnit-like pseudo code (within a TestFixture)
Ctor()
{
m_globalVar = getFoo();
}
[Test]
Create()
{
a(m_globalVar)
}
[Test]
Delete()
{
// depends on Create being run
b(m_globalVar)
}
... hoặc ...
// NUnit-like pseudo code (within a TestFixture)
[Test]
CreateAndDelete()
{
Foo foo = getFoo();
a(foo);
// depends on Create being run
b(foo);
}
... Tôi đi với sau này, và giả định rằng câu trả lời cho câu hỏi của tôi là:
Không, ít nhất là không với NUnit, bởi vì according to the NUnit manual:
Nhà xây dựng không nên có bất kỳ tác dụng phụ nào, vì NUnit có thể xây dựng nhiều lớp học es trong quá trình phiên.
... ngoài ra, tôi có thể giả định thực tiễn không tốt nói chung không? Vì các thử nghiệm thường có thể được chạy riêng. Vì vậy, kết quả của Tạo có thể không bao giờ bị xóa bởi Xóa.
Tôi đồng ý với điều này nhưng không phải tất cả đều thấy TestNG http://testng.org/doc/index.html là một cải tiến về jUnit theo nhiều cách nhưng cũng cho phép kiểm tra phụ thuộc - đặc biệt là xem http: // beust.com/weblog/2004/02/08/junit-pain/vì lý do của authour – Mark
@Mark, tôi không quen thuộc với TestNG, cảm ơn vì liên kết. –
@Mark: Lý do được đưa ra trong liên kết thứ hai thực sự là quan trọng. Đối với các bài kiểm tra đơn vị, cơ sở dữ liệu nên được giả lập và vì vậy chi phí thiết lập và rách tài nguyên sẽ bị bỏ qua, và để kiểm tra tích hợp, bạn có thể chi trả chi phí (bạn cũng phải làm những việc như đặt cơ sở dữ liệu vào một trạng thái đã biết và những thứ như thế, có thể có tác động khá lớn đến bản thân họ). –