JUnit report UET n5 autumn 2013
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (403.63 KB, 38 trang )
A tool for test-driven development
Team work:
Vũ Đức Luận(c)
Nguyễn Tiến Đạt
Nguyễn Khánh Thiện
Các Vấn đề cần làm rõ:
1.xUnit framework?
2.Lịch sử phát triển Junit
3.Kiến trúc tổng quan
4.Tại sao phải tạo 1 test suit?
5.Cách viết 1 Testcase
6.Các phương thức Assert
7.Set Up và Tear Down
8.Test Exception
9.Junit in Eclipse
10.Các công cụ Testing khác
Phân chia công việc
Nguyễn Khánh Thiện Vũ Đức Luận Nguyễn Tiến Đạt
1.xUnit framework?
2.Lịch sử phát triển Junit
3.Kiến trúc tổng quan
4.Tại sao phải tạo 1 test
suit?
5.Cách viết 1 Testcase
6.Các phương thức Assert
7.Set Up và Tear Down
8.Test Exception
9.Junit in Eclipse
10.Các công cụ Testing
khác
Nó liên quan đến việc kiểm tra các đơn vị cơ bản của phần mềm . Những
đoạn code của unit testing hướng tới mục tiêu là các đơn vị đối tượng cụ
thể nào đó , kiểm tra đầu vào đầu ra , một chi tiết một thời điểm cụ thể .
xUnit framework là họ của các unit testing frameworks với những ngôn
ngữ và các nền tảng lập trình khác nhau .
Danh sách unit testing framework :
o
o
o
o
!
o
""#$
o
!%%!
o
&&
o
''
Lịch sử phát triển Junit
JUnit là một framework đơn giản dùng cho việc tạo các unit
testing tự động, và chạy các test có thể lặp đi lặp lại.
JUnit là một chuẩn trên thực tế cho unit testing trong Java.
JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma và Kent
Beck.
o
Vào giữa những năm 90 của thế kỷ 20 , Kent Beck đã phát triển một bộ
test xUnit đầu tiên cho Smalltalk .
o
Beck và Gamma phát triển JUnit trên một chuyến bay từ Zurich đến
Washington, DC.Từ đó Junit trở thành công cụ chuẩn cho Test-Driven
Development trong Java .
o
Ngày nay, JUnit được tích hợp sẵn trong các Java IDEs (Eclipse, BlueJ,
Jbuilder, DrJava) .
Kiến trúc tổng quan
JUnit test framework cung cấp cho chúng ta các gói lớp có sẵn
cho phép chúng ta viết các phương thức test một cách dễ dàng .
TestRunner sẽ chạy các test và trả về kết quả là các Test Results
Các lớp của chương trình test chúng ta sẽ được kế thừa các lớp
trừu tượng TestCase .
Khi viết các Test Case chúng ta cần biết và hiểu lớp
Assert class .
Một số định nghĩa trong mô hình tổng quát :
o
Test case : test case định nghĩa môi trường mà nó có thể sử dụng để chạy
nhiều test khác nhau
o
TestSuite : testsuite là chạy một tập các test case và nó cũng có thể bao
gồm nhiều test suite khác . test suite chính là tổ hợp các test .
Tại sao phải tạo 1 testsuit
Obviously you have to test your code—right?
You can do ad hoc testing (running whatever tests occur to you at
the moment), or
You can build a test suite (a thorough set of tests that can be run at
any time)
Disadvantages of a test suite
It’s a lot of extra programming
True, but use of a good test framework can help quite a bit
You don’t have time to do all that extra work
False! Experiments repeatedly show that test suites reduce debugging
time more than the amount spent building the test suite
Advantages of a test suite
Reduces total number of bugs in delivered code
Makes code much more maintainable and refactorable
Thông thường JUnit tự động tạo ra các Test Suite ứng
với mỗi Test Case. Tuy nhiên bạn muốn tự tạo các
Test Suite của riêng mình bằng cách tổ chức
các Test vào Test Suite. JUnit cung cấp lớp
junit.framework.TestSuite hỗ trợ việc tạo các Test
Suite
Khi bạn sử dụng giao diện text hay graphic, JUnit sẽ
tìm phương thức sau trong test case của bạn:
public static Test suite() { … }
Nếu không thấy phương thức trên, JUnit sẽ sử dụng
kỹ thuật reflection.
Tại sao phải tạo 1 testsuit
( ) ##)#*)+#)#!#,))
-))
( )# )#)#./),))
))#.#* ##/0))
1)))
1)
Bằng cách truyền đối tượng TestGame.class vào
construtor TestSuite, bạn đang thông báo cho JUnitbiết để
xác định tất cả các phương thức testXXX() trong lớp đó và
thêm chúng vào suite. Đoạn mã trên không làm khác gì so
với việc JUnit tự động làm, tuy nhiên bạn có thể thêm các
test cá nhân để chỉ chạy các test nhất định nào đó hay là điều
khiển thứ tự thực thi
()20))
( ) ##)#*)+#)#!#),))
()*)$0))
()&()$&0))
( )#*.$)/),))
#(./0))
1))
-))
( )# )#)#./),))
#)#)3))#./0))
#++#.)#*.4#!$&4//0))
#++#.)#*.4#$//0))
)#0))
1))
1))
Cách viết 1 Testcase
##$5 # ##TestCase5& &6++
#&+#
"7### ##8
(#!#0
( ###+##!#,
199#6 ##
: ###(;#&+&Test6!##
6!##Test
&#$ ##< 6+6#
###
Cách viết 1 phương thức trong TestCase
#programming by contract(+$8
(preconditions
= # 6$#+
!& postconditions
=(8
( +#=(6#./,
(63./0
##=>#.?@(6##&+@A5
B5(6##@.//0
##.?(6#&+((6A5 (6#=(6.//0
1
&$# 8
( &+#$;( +testC&./
o
#&++ + 66
!+$#(
: &##6( #-
( ) ##)#),))
()$)#:0))
()$)#:0))
( )#.$)#:5)$)#:/),))
).#:)33))DD)#:)33)/),))
&))E$$= (.4&)#) ))4/0))
1))
&##:)3)#:0))
&##:)3)#:0))
1))
( )$)$:./),))
$)#)3).&##:)F3)/)G)&##:)8)4G40))
$)#)3).&##:)F3)/)G)&##:)8)4G40))
)#)%)#0))
1))
( )$)$#:./),))
)&##:0))
1))
( )$)$#:./),))
)&##:0))
1
1
()#!#0))
( ) ##)##)+#)#!#),))
( )##.$)/),))
#(./0))
1))
922)
2)H )&)$))+ )&)&)+$)+&)+$)
29))
( )+)#*:./),))
#)()3))#.4+45)44/0))
##=>#.4+)45)($:.//0))
1))
922)
2)H )&)$)#)+)+ ))6) &&) )
29))
( )+)#:#E:./),))
#)()3))#.5)44/0))
##=>#.4G)45)($:.//0))
()3))#.445)/0))
##=>#.4)G45)($:.//0))
1))
1
Các phương thức assertXXX()
!I (& $& )ươ ứ assertXXX())J +K$J I ượ ể ể
J &I &ề ệ junit.framework.TestCase5 ( &ớ
& I # #5& (ấ ả ừ ế ừ ớ
##
(L6J &$&M&I& I (& $ớ ị ề ươ
& )ứ assertXXX().
!I (& $& #& J $ $ I &$ & $ươ ứ ạ ộ ằ ọ ữ
(& $& L6ươ ứ
JN6LO I (& $& ##HHH./&I &ả ươ ứ
P$ (ớ ##8
Các phương thức assert()
assertFalse(): Đánh giá biểu thức . Test sẽ được chấp nhận nếu
biểu thức sai
assertTrue(): Đánh giá một biểu thức . Test sẽ được chấp nhận
nếu biểu thức đúng
assertNotNull(): So sánh tham chiếu của một đối tượng với null.
Test sẽ được chấp nhận nếu tham chiếu đối tượng khác null
assertNotSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đối
tượng bằng cách sử dụng toán tử ==. Test sẽ được chấp nhận nếu
cả 2 đều tham chiếu đến các đối tượng khác nhau
Các phương thức assert()
assertNull(): So sánh tham chiếu của một đối tượng với giá trị
null. Test sẽ được chấp nhận nếu tham chiếu là null
assertSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đối
tượng bằng cách sử dụng toán tử ==. Test sẽ được chấp nhận nếu
cả 2 đều tham chiếu đến cùng một đối tượng
fail(): Phương thức này làm cho test hiện hành thất bại, phương
thức này thường được sử dụng khi xử lý các biệt lệ
assertEquals(): So sánh 2 giá trị để kiểm tra bằng nhau. Test sẽ
được chấp nhận nếu các giá trị bằng nhau
Chú ý8Mặc dù bạn có thể chỉ cần sử dụng phương thức assertTrue() cho
gần như hầu hết các test, tuy nhiên thì việc sử dụng một trong các
phương thức assertXXX() cụ thể sẽ làm cho các test của bạn dễ hiểu hơn và cung
cấp các thông điệp thất bại rõ ràng hơn.
Tất cả các phương thức của bảng trên đều nhận vào một String không bắt
buộc làm tham số đầu tiên. Khi được xác định, tham số này cung cấp một
thông điệp mô tả test thất bại.
Ví dụ:
1.assertEquals(employeeA, employeeB);
2.assertEquals(“Employees should be equal after the clone() operation.”,
employeeA, employeeB).
Phiên bản thứ 2 được ưa thích hơn vì nó mô tả tại sao test thất bại, điều
này sẽ giúp cho việc sửa lỗi được dễ dàng hơn
Thế nào là một unit test tốt
99 ##*
( ) ##)*),))
()()#&(#)3))"#&(./0))
( )*./)&#)+*= (),))
1))
( )+)#&+./),))
99)+6)&+))
1))
( )#6 &@+)&() $&.$)$&E+/),))
&()#)3).&(/)&##&(#$.$&E+/0))
).#)33)/),))
#)3))&(.$&E+/0))
&##&(#(.$&E+5)#/0))
1))
)#0))
1))
( ))#6$./),))
)#0))
1))
1))
( ) ##)+*= ()+#)= (),))
( )+*= (.$)#/),))
#(.#/0))
1))
1))
Sau đó ta viết một đoạn test sau đây:
99#*Q
( )+)#*./)&#)+*= (,))
*)$)3))*./0))
&()$&)3)$ $&.?BBQA/0))
##=>#.4$&)++))&)&) )+45)4BBQ45)
&#$&$E+.//0))
&()$&R)3)&#$ $&.4BBQ4/0))
##.?!$&)&)#)+)#&+))#) 45)$&5
)$&R/0))
##.4))$)#&+)))#+)645)F&#$#6$.//0))
1))
Mỗi unit test chỉ nên kiểm tra phần cụ thể của một chức năng
nào đó. Chúng ta không nên kết hợp nhiều test không liên
quan với nhau lại vào trong một phương thức testXXX()
Đây là một thiết kế không tốt vì mỗi phương
thức assertXXX() đang kiểm tra phần không liên quan của
chức năng. Nếu phương thức assertEquals() thất bại, phần
còn lại của test sẽ không được thi hành. Khi xảy ra điều này thì
chúng ta sẽ không biết các test khác có đúng chức năng hay
không
Tiếp theo chúng ta sẽ sửa test trên lại để kiểm tra các khía cạnh
khác nhau của trò chơi một cách độc lập.
99#*R
( )+)#!$&./),))
6#(.4$)#!$&./4/0))
##=>#.4$&)++))&)&) )+45)4BBQ45)&#$&$E+.//0))
6#(.4=+)#!$&./4/0))
1))
( )+)#$&#./),))
6#(.4$)#$&#./4/0))
&()$&R)3)&#$ $&.4BBQ4/0))
##.?!$&)&)#)+)#&+))#) 45)&#$&5)$&R/0))
6#(.4=+)#$&#./4/0))
1))
( )+)#*E./),))
6#(.4$)#*E./4/0))
##.4))$)#&+)))#+)645)F&#$#6$.//0))
6#(.4=+)#*E./4/0))
1))
Với cách tiếp cận này, khi một test thất bại sẽ không làm cho
các mệnh đề assertXXX() còn lại bị bỏ qua.
Có thể bạn sẽ đặt ra câu hỏi có khi nào một phương thức test
chứa nhiều hơn một các phương thức assertXXX() hay
không? Câu trả lời là có. Nếu bạn cần kiểm tra một dãy các
điều kiện và các test theo sau sẽ luôn thất bại nếu có một test
đầu tiên thất bại, khi đó bạn có thể kết hợp nhiều phương
thức assert vào trong một test
