1. Trang chủ
  2. » Công Nghệ Thông Tin

Kiểm thử phần mềm với JUnit

63 1,4K 34

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 63
Dung lượng 892,28 KB

Nội dung

Mục lục LỜI CẢM ƠN Phần 1: Mở đầu 1. Tên đề tài 2. Lí do lựa chọn đề tài 3. Mục đích 4. Bố cục 5. Phương pháp Phần 2: Nội dung Chương 1: Cơ sở lý thuyết 1.1 Tổng quan về kiểm thử phần mềm 1.2 Kiểm thử tự động 1.3 Kiểm thử đơn vị Chương 2: Kiểm thử với JUnit 2.1 Junit là gì? 2.2 Lợi ích của Junit 2.3 Cách sử dụng cơ bản 2.4 JunitAPI (Giao diện lập trình ứng dụng) 2.5 Tổ chức các phép thử 2.6 Viết bài kiểm tra Chương 3: Cài đặt và Demo 3.1 Cài đặt 3.2 Demo trên Netbeans Phần 3: Kết luận Tài liệu tham khảo

Trang 1

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

KIỂM THỬ PHẦN MỀM

Đề tài: Tìm hiểu kiểm thử phần mềm với JUnit

GIÁO VIÊN HƯỚNG DẪN : NGUYỄN ĐỨC LƯU

NHÓM THỰC HIỆN : NHÓM 20

Trang 2

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

KIỂM THỬ PHẦN MỀM

Đề tài: Tìm hiểu kiểm thử phần mềm với JUnit

GIÁO VIÊN HƯỚNG DẪN : NGUYỄN ĐỨC LƯU

Trang 3

Mục lục

LỜI CẢM ƠN 1

Phần 1: Mở đầu 2

1 Tên đề tài 2

2 Lí do lựa chọn đề tài 2

3 Mục đích 3

4 Bố cục 3

5 Phương pháp 3

Phần 2: Nội dung 4

Chương 1: Cơ sở lý thuyết 4

1.1 Tổng quan về kiểm thử phần mềm 4

1.2 Kiểm thử tự động 6

1.3 Kiểm thử đơn vị 10

Chương 2: Kiểm thử với JUnit 12

2.1 Junit là gì? 12

2.2 Lợi ích của Junit 12

2.3 Cách sử dụng cơ bản 13

2.4 Junit-API (Giao diện lập trình ứng dụng) 19

2.5 Tổ chức các phép thử 33

2.6 Viết bài kiểm tra 37

Trang 4

Chương 3: Cài đặt và Demo 43

3.1 Cài đặt 43

3.2 Demo trên Netbeans 47

Phần 3: Kết luận 50

Tài liệu tham khảo 51

Trang 5

LỜI CẢM ƠN

Trong suốt quá trình học tập và làm bài tập lớn, nhóm 20 đã nhận được sự hướng dẫn, giúp đỡ nhiệt tình của quý thầy cô trong khoa Công nghệ thông tin trường Đại học Công nghiệp Hà Nội và các bạn trong bộ môn để hoàn thành đề tài nghiên cứu của nhóm Với lòng kính trọng và sự biết ơn sâu sắc, nhóm 20 xin được bày tỏ lời

cảm ơn chân thành tới thầy Nguyễn Đức Lưu – người thầy đã hết lòng giúp đỡ, dạy

bảo, động viên và tạo mọi điều kiện thuận lợi cho nhóm trong suốt quá trình học tập

và hoàn thành bài tập lớn của nhóm, cùng tất cả các thầy cô trong khoa, trong trường

và bạn bè trong bộ môn đã giúp đỡ nhóm trong quá trình học tập.

Những đóng góp của mọi người là kinh nghiệm quý báu giúp cho các thành viên trong nhóm sẽ có những dự tính sau này trong khi làm đồ án tốt nghiệp và sau khi tốt nghiệp.

Chúng em xin chân thành cảm ơn!

Nhóm thực hiện Nhóm 20

Trang 6

về chất lượng phần mềm theo chiều sâu Nhưng cũng từ

đó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc phần mềmkhông đáng có gây ra các ảnh hưởng nghiêm trọng đến xãhội, kinh tế, Những lỗi này có thể do tự bản thân phầnmềm bị hỏng do không được kiểm duyệt kĩ lưỡng trước khiđưa cho người dùng cuối hay cũng có thể do có người cốtình phá hoại nhằm đánh cắp thông tin cá nhân như mã sốtài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn, Những vấn đề nan giải và cấp thiết này càng có xu hướng

mở rộng trong các năm gần đây, điển hình như sự cố máytính Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớnhay như càng có nhiều loại virus phá hoại mới xuất hiện,tấn công vào các lỗ hổng bảo mật phần mềm làm tê liệtnhiều hệ thống phần mềm và phần cứng Từ đây ta dễdàng nhận ra là mặc dù phần mềm phát triển ngày càngphức tạp nhưng vấn đề chất lượng vẫn là một dấu hỏi lớncần xem xét cẩn thận Tuy nhiên, việc kiểm thử chưa thực sự phổbiến trong chương trình giảng dạy lập trình và công nghệ phần mềm tại

Trang 7

một số trường đại học ở nước ta Người lập trình thường xem nhẹ việckiểm thử, đơn giản vì đó là một công việc nhàm chán, ít gây hứng thú.Nhưng kiểm thử là một hoạt động quan trọng và không thể thiếu đượcnhằm phát hiện lỗi trong chương trình, từ đó nâng cao năng suất và đảmbảo chất lượng sản phẩm phần mềm Beck và Gamma là những ngườiđầu tiên phát triển công cụ mã nguồn mở JUnit để hỗ trợ việc kiểm thử.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 Nó chỉ là một phần của họkiến trúc xUnit cho việc tạo các unit testing JUnit là một chuẩn trên thực

tế cho unit testing trong Java và rất phổ biến hiện nay.Vì vậy, chúng emchọn đề tài “Tìm hiểu kiểm thử phần mềm với JUnit” đề được nghiên cứu

và hiểu rõ hơn về JUnit

 Chương 1: Lý thuyết về kiểm thử và kiểm thử tự động

 Chương 2: Kiểm thử tự động với JUnit

 Chương 3: Cài đặt JUnit và Test demo bằng JUnit

5 Phương pháp

- Nghiên cứu, tìm hiểu các kỹ thuật nội dung của kiểm thử tự động JUnit

- Sử dụng kiến thức đã tổng hợp được để demo test cho chương trình cụ thể

Trang 8

Phần 2: Nội dung

Chương 1: Cơ sở lý thuyết1.1 Tổng quan về kiểm thử phần mềm

1.1.1 Khái niệm Kiểm thử phần mềm

- là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụphần mềm trong đúng môi trường chúng dự định sẽ đượctriển khai nhằm cung cấp cho những người có lợi ích liên quannhững thông tin về chất lượng của sản phẩm hay dịch vụphần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra cáclỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạtđộng tối ưu của phần mềm trong nhiều ngành khác nhau.(Wikipedia) Software testing là một trong những kĩ thuật phầnmềm “ xác minh và xác nhận “ (verification and validationhay gọi tắt là V&V) Verification (chữ V đầu tiên) là quá trìnhđánh giá một hệ thống hoặc thành phần để xác định xem cácsản phẩm của một giai đoạn phát triển nhất định đáp ứng cácđiều kiện áp đặt vào lúc bắt đầu của giai đoạn đó hay không.Các hoạt động Verification bao gồm việc kiểm thử và đánhgiá Ví dụ trong phần mềm chơi game Monopoly, chúng ta cóthể xác minh rằng hai người chơi không thể sở hữu cùng mộtnhà Validationis quá trình đánh giá một hệ thống hoặc mộtthành phần trong hoặc ở cuối của quá trình phát triển để xácđịnh xem nó đáp ứng yêu cầu quy định Verification ValidationThông qua Verification chúng ta muốn chắc chắn rằng phầnmềm có các hành vi đúng như chúng ta mong đợi Ví dụ:Trong game Monopoly, người chơi có thể được cộng 200 điểm

Trang 9

nếu họ hạ cánh trên sân hoặc đi qua Go nhưng người lập trìnhlại cài đặt là người chơi phải đi qua Go(?!) Thông quaValidation chúng ta sẽ xác nhận rằng những lỗi không đúngvới yêu cầu của khách hàng sẽ không được thực hiện tiếptheo trong suốt quá trình xây dựng xây dựng phần mềm.Validation luôn luôn liên quan tới việc so sánh với các yêu cầucủa khách hàng Ví dụ khách hàng yêu cầu là làm cho họgame Monopoly nhưng đội ngũ phát triển lại làm đưa chogame Life vì họ nghĩ là game Life hay hơn game Monopolynhư yêu cầu ban đầu

1.1.2 Vai trò của kiểm thử phần mềm

- Việc tạo ra 1 sản phẩm phần mềm phải trải qua nhiềugiai đoạn, người ta gọi là qui trình phát triển phần mềm, bắtđầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩmphần mềm thực thi Khối lượng công việc trong từng giai đoạncủa quá trình sản xuất phần mềm cũng thay đổi theo thờigian Một sản phẩm phần mềm không chỉ đơn giản là cácđoạn mã chương trình mà còn rất nhiều phần ẩn đằng sau nó

Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình màcòn xảy ra cao hơn trong các công đoạn khác của qui trìnhphát triển một sản phẩm phần mềm Việc kiểm thử cũng vìthế phải được tiến hành trong tất cả các phần tạo nên mộtsản phẩm phần mềm

1.1.3 Các kĩ thuật kiểm thử phần mềm

 Kiểm thử hộp đen (Black Box testing): Dùng để kiểmtra chức năng mà không xem xét mã nguồn cũng như

Trang 10

cấu chúc chương trình bên trong Thường kiểm thửhộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thửđầu vào.

 Kiểm thử hộp trắng (White Box testing): Khác với kiểmthử hộp đen, kiểm thử hộp trắng xem xét mọi moduletrong chương trình, các luồng thực hiện công việc để

từ đó đưa ra các chiến lược kế hoạch cụ thể cho việckiểm thử

 Kiểm thử hộp xám (Grey Box Testing): Đây là một kĩthuật kiểm thử mới dựa trên những đặc tính của cảkiểm thử hộp đen và hộp trắng Mục tiêu chính củakiểm thử hộp xám là kiểm thử các ứng dụng trên nềnweb (web based)

1.1.4 Các giai đoạn hay cấp độ kiểm thử phần mềm

 Kiểm thử đơn vị (Unit test): kiểm thử từng module nhỏtrong chương trình để tìm ra các lỗi và khắc phục

 Kiểm thử tích hợp: sau khi đã thực hiện thành côngkiểm thử đơn vị, ta sẽ tiến hành tích hợp các modulenày với nhau và kiểm thử trên toàn bộ khối mã lệnh đãtích hợp này

 Kiểm thử hệ thống (System test): kiểm thử trên toàn

bộ ứng dụng

 Kiểm thử chấp nhận (Acceptance Test): khâu này dokhách hàng trực tiếp đảm nhận trước khi bàn giao sảnphẩm chính thức

 Kiểm thử hồi quy là hoạt động trợ giúp để đảm bảorằng các thay đổi không đưa ra những hành vi hoặcnhững lỗi bổ sung không mong đợi

Trang 11

1.1.5 Một số loại hình kiểm thử phổ biến

Hiện nay, do sự phát triển mạnh mẽ của công nghệmphần mềm nên có một số loại hình kiểm thử tiêu biểu như:

 Kiểm thử các phần mềm trên Desktop: đây là các ứngdụng được cài đặt trực tiếp trên máy tính cá nhânnhằm thực hiện các chức năng theo yêu cầu ngườidùng Đây vẫn đang là những ứng dụng phổ biến nhất

 Kiểm thử Web hay kiểm thử trên đám mây: với sự lớnmạnh của Internet thì các ứng dụng web cũng ngàycàng phát triển và đang dần thay thế các ứng dụngtrên Desktop truyền thống như Google Document,Microsoft web apps,

 Kiểm thử trên Mobile: ngày nay xã hội với sự phát triểnnhanh chóng, các thiết bị di động (điện thoại thôngminh, máy tính bảng, ) có số lượng người dùng cũngđang tăng lên chóng mặt, cùng với đó là số lượngphần mềm phục vụ cho nhu cầu cũng tăng cao vì vậyđây là một lĩnh vực đầy tiềm năng và thách thức trongcông nghệ phần mềm

1.2 Kiểm thử tự động

1.2.1 Kiểm thử tự động là gì?

Sử dụng một công cụ kiểm thử tự động để thực thi cáctest cases thay cho con người được goi là kiểm thử tựđộng Công cụ kiểm thử tự động có thể lấy dự liệu từ filebên ngoài (excel, csv, …) nhập vào ứng dụng, so sánh kết

Trang 12

quả mong đợi (từ excel, csv) với kết quả thực tế và xuất

ra báo cáo kết quả kiểm thử

1.2.2 Ưu điểm và nhược điểm của kiểm thử tự động

Ưu điểm:

 Độ tin cậy cao(Reliability): Nhờ sự ổn định vượt trội củacông cụ kiểm thử tự động so với con người, đặc biệttrong trường hợp có quá nhiều test cases cần được thựcthi, nên độ tin cậy của kiểm thử tự động thường caohơn so với kiểm thử thủ công

 Khả năng lặp (Repeatability): Hãy cùng xem xet một vídụ: Trong một ngày thời tiết xấu chúng ta phải thực thimột test case với 50 bộ dữ liệu đầu vào khác nhau Nếuthực thi cách thủ công, ngồi trước màn hình, nhập dữliệu, click click , check check … trong 50 lần có lẽ bạn

sẽ gục ngã sớm trên bàn làm việc của mình NHƯNG,nếu bạn thực thi bằng kiểm thử tự động, chỉ cần nhập

dữ liệu vào file excel ( or csv, …) cho script chạy vàngồi rung đùi cho tới khi nhận được báo cáo Với độ ổnđịnh cao, bạn hoàn toàn có thể tin tưởng vào kết quảthực thi của công cụ kiểm thử tự động Quả là một viễncảnh lý tưởng hơn nhiều

 Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử

tự động, chúng ta có thể sử dụng cho nhiều phiển bảnứng dụng khác nhau, đây được gọi là tính tái sử dụng

 Nhanh (Fast): Đây là điều không cần phải bàn cãi, nếucần 5 phút để thực thi một test case cách thủ công, cóthể bạn cần chưa đầy 30s để thực thi cách tự động

Trang 13

 Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tựđộng đúng cách, chúng ta có thể tiết kiệm được rất nhiều chi phí, thời gian và nhân lực

Nhược điểm:

 Khó mở rộng, khó bảo trì (Poor scalability andmaintainability): Trong cùng một dự án, để mở rộngphạm vi cho kiểm thử tự động là khó hơn nhiều so vớikiểm thử cách thủ công Số lượng công việc phải làm để

mở rộng phạm vi cho kiểm thử tự động là nhiều hơn vàkhó hơn kiểm thử thủ công Cũng vậy, để cập nhật mộttest case thủ công, chúng ta chỉ cần mở ra và gõ, rấtđơn giản Nhưng kiểm thử tự động lại không đơn giảnnhư vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiềucông việc như debug, thay đổi dữ liệu đầu vào, và cậpnhật code mới

 Khả năng bao phủ thấp(Low coverage): Chính vì việckhó ứng dụng, khó mở rộng, cũng như đòi hỏi quá nhiều

kỷ năng lập trình nên độ bao phủ của kiểm thử tự độngkhá thấp (xét trên góc nhìn toàn dự án)

 Vấn đề công cụ và nhân lực (Technology vs peopleissues): Cho đến nay công cụ hỗ trợ kiểm thử tự động

đã có những bước phát triển mạnh mẽ, chúng ta có cáccông cụ rất tốt như QTP, Selenium, Test Complete,LoadTest, Jmeter, Visual Studio, … Nhưng nhìn chungvẫn còn rất nhiều mặt hạn chế Ngoài ra nguồn nhânlực đạt yêu cầu cũng không nhiều

Trang 14

 Tiết kiệm tiền bạc vời thời gian: Nhận định này đặc biệtđúng nếu xét trong giai đoạn bảo trì của các dự án lớn.Mỗi tuần chúng ta phải thực hiện regression test từ 1đến 2 lần với số lượng test case rất lớn trong 1 đến 2ngày Gần như không thể thực hiện cách thủ công, trongkhi với kiểm thử tự động chúng ta hoàn toàn có thể vớinguồn nhân lực vô cùng khiêm tốn.

 Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động cóthể thực thi các test case với độ chính xác cao hơn

 Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử

tự động, chúng ta có thể thực thi số lượng lớn test casetrong một thời gian ngắn Điều này giúp chúng ta tăng

độ bao phủ trong giai đoạn regression test (một ví dụđiển hình)

 Hoàn thành các công việc mà con người không thể làmđược: Nếu chúng ta muốn thực thi load test,performance test, thì kiểm thử tự động là cách duy nhất.1.2.4 Khi nào nên sử dụng kiểm thử tự động

 Lý do thường xuyên nhất dẫn đến quyết định sử dụngkiểm thử tự động là thường xuyên phải thực thiregression test Từ khi DEV đưa ra bản build mới cho tớikhi phiên bản mới tới tay khách hàng chỉ từ 1 đến 2ngày Trong thời gian ngắn ngủi này, regression test sẽđược thực thi, nghĩa là một số lượng test case lớn phảiđược thực thi trong một khoảng thời gian ngắn Đây làlúc lý tưởng để sử dụng kiểm thử tự động

 Xây dựng một bộ kiểm thử tự động cho những functionchính, để thực thi smoke test mỗi khi có build mới cũng

Trang 15

là một ý tưởng hay Đây là công việc rất thường xuyêntrước khi thực hiện regression test.

 Như đã nhắc tới ở trên, khi chúng ta muốn thực thiperformance test hay load test, kiểm thử tự động gầnnhư là lựa chọn duy nhất

 Khi số lượng đầu vào của 1 test case quá nhiều (như ví

dụ 50 bộ dữ liệu test), chúng ta cũng nên xem xét khảnăng thực hiện kiểm thử tự động

Trang 16

1.3Kiểm thử đơn vị

1.3.1 Tổng quan về kiểm thử đơn vị

Mục đích:

o Kiểm tra đơn vị thiết kế nhỏ nhất – Một module phần mềm

o Người tiến hành kiểm thử đơn vị

o Lập trình viên và nhóm của mình

o Kỹ thuật kiểm thử đơn vị

Chủ yếu là kiểm thử hộp trắng, nhưng đôi khi người ta cũng có thể sửdụng kiểm thử hộp đen

1.3.2 Mô hình kiểm thử đơn vị

Trang 17

1.3.2 Kỹ thuật kiểm thử đơn vị

1.3.3 Nội dung của kiểm thử đơn vị

 Kiểm thử giao diện

 Kiểm thử vào/ra

 Kiểm thử cấu trúc dữ liệu cục bộ

 Kiểm thử xử lý

 Kiểm thử điều kiện logic

 Kiểm thử sai tiềm ẩn

 Kiểm thử các giá trị biên

Trang 18

Chương 2: Kiểm thử với JUnit2.1 Junit là gì?

 Các ngôn ngữ lập trình như như ASP, C++, C, Delphi,Perl, PHP, REBOL, Python,… đều có bộ hỗ trợ Unit Testriêng của nó JUnit là một framework được dùng cho UnitTest trong Java JUnit được xây dựng bởi Erich Gamma

và Kent Beck, hai người nổi tiếng nhất về lập trình XP

 Trong JUnit có các Test Case là các lớp của Java, các lớpnày bao gồm một hay nhiều các phương thức cần kiểmtra, và Test Case này lại được nhóm với nhau để tạothành Test Suite Mỗi phương thức thử trong JUnit phảiđược thực thi nhanh chóng Tốc độ ở đây là điều tối quantrọng vì càng nhiều phép thử được viết và tích hợp vàobên trong quá trình phần mềm thì càng tốn nhiều thờigian để hơn cho việc chạy toàn bộ Test Suite

 Những người lập trình không muốn bị ngắt quãng trongmột thời gian dài trong khi các phép thử đang chạy, do

đó các phép thử mà càng chạy lâu thì sẽ có nhiều khảnăng là các lập trình viên sẽ bỏ qua bước này Các phépthử được thiết kế để khi chạy mà không cần có sự canthiệp của con người

 Mỗi phép thử trong JUnit là một phương thức public,không có đối số và được bắt đầu bằng chữ test( testXXX()) Nếu chúng ta không tuân thủ theo qui tắcnày thì JUnit sẽ không xác định được các phương thứctest một cách tự động

Trang 19

2.2 Lợi ích của Junit

JUnit tránh cho người lập trình phải làm đi làm lại nhữngviệc kiểm thử nhàm chán bằng cách tách biệt mã kiểm thử

ra khỏi mã chương trình, đồng thời tự động hóa việc tổ chức

và thi hành các bộ số liệu kiểm thử

Thoạt tiên, khi sử dụng JUnit, ta có thể có cảm giác làJUnit chỉ làm mất thêm thời gian cho việc kiểm thử: Thay vìphải viết thêm các lớp và phương thức mới phục vụ cho côngtác kiểm thử, ta có thể soạn nhanh một bộ số liệu rồi viếtngay vào trong phương thức main() và quan sát ngay kếtquả kiểm thử Vì quá trình soạn số liệu và quá trình kiểm thửdiễn ra đồng thời, nên ta sẽ dễ dàng nhận biết được ngaychương trình đã chạy đúng trên bộ số liệu kiểm thử haykhông, mà không cần nhìn vào tín hiệu “xanh” mà JUnit cóthể hỗ trợ

Nhưng khi tổ chức lại chương trình cho hợp lý hơn(refactoring) hoặc khi phải thay đổi chương trình để phục vụcho nhu cầu mới, các bộ số liệu kiểm thử trước đây sẽ cầnđược sử dụng lại để chắc chắn rằng những thay đổi trongchương trình không làm phương hại đến những thành quảtrước đó, lúc này ta sẽ phải mất thời gian để tìm hiểu lại xem

bộ số liệu trước đây sẽ tương ứng với kết xuất gì vì ta khôngthể nhớ hết mọi hoạt động kiểm thử đã diễn ra Việc nhớ lạinhững kiểm thử đã qua sẽ chẳng thú vị vì không đem đếncho ta điều gì mới Nếu phải kiểm thử trên những bộ số liệulớn thì gánh nặng của việc tổ chức kiểm thử sẽ chồng chấtthêm JUnit giúp người lập trình tự động hóa các công việc

Trang 20

nhàm chán, và chỉ cần nhìn thấy tín hiệu “xanh” là người lậptrình có thể an tâm rằng module đã được lập trình đúng.

public class MessageUtil {

private String message;

//Constructor

//@param message to be printed

public MessageUtil(String message){

this.message = message;

}

Trang 21

// prints the message

public String printMessage(){

System.out.println(message);

return message;

}

}

 Tạo lớp kiểm tra

Tạo một lớp kiểm tra java, TestJunit.java

Thêm một phương pháp thử nghiệm testPrintMessage () vào lớp kiểm tra của bạn

Thêm Annotaion @Test to method testPrintMessage ()

Thực hiện điều kiện kiểm tra và kiểm tra điều kiện sử dụng assertEquals API của JUnit

Tạo một tên tệp java class TestJunit.java trong C:\> JUNIT_WORKSPACE

import org.junit.Test;

import static org.junit.Assert.assertEquals;

Trang 22

public class TestJunit {

String message = "Hello World";

MessageUtil messageUtil = new MessageUtil(message);

@Test

public void testPrintMessage() {

assertEquals(message,messageUtil.printMessage()); }

}

 Tạo lớp chạy thử

Tạo một lớp java TestRunner

Sử dụng phương pháp runClasses của lớp JUnitCore của JUnit để chạy trường hợp thử nghiệm của lớp test đã tạo ở trên

Nhận kết quả của các trường hợp thử nghiệm chạy trong Đối tượng kết quả

Nhận lỗi (s) bằng phương thức getFailures () của đối tượngResult

Trang 23

Nhận kết quả bằng cách sử dụng phương thức

wasSuccessful () của đối tượng Result

Tạo tệp tin lớp java có tên TestRunner.java trong C:\

>JUNIT_WORKSPACE để thực hiện (các) trường hợp kiểm tra

import org.junit.runner.JUnitCore;

import org.junit.runner.Result;

import org.junit.runner.notification.Failure;

public class TestRunner {

public static void main(String[] args) {

Result result = JUnitCore.runClasses(TestJunit.class);

for (Failure failure : result.getFailures()) {

System.out.println(failure.toString());

}

System.out.println(result.wasSuccessful());

}

Trang 24

Biên dịch MessageUtil, Test case và Test Runner classes

import org.junit.Test;

import static org.junit.Assert.assertEquals;

public class TestJunit {

String message = "Hello World";

MessageUtil messageUtil = new MessageUtil(message);

Trang 25

@Test

public void testPrintMessage() {

message = "New Word";

assertEquals(message,messageUtil.printMessage()); }

}

Hãy giữ phần còn lại của các lớp học như là, và cố gắng

để chạy Runner Test giống nhau

import org.junit.runner.JUnitCore;

import org.junit.runner.Result;

import org.junit.runner.notification.Failure;

public class TestRunner {

public static void main(String[] args) {

Result result = JUnitCore.runClasses(TestJunit.class);

Trang 26

for (Failure failure : result.getFailures()) {

System.out.println(failure.toString());

2.4 Junit-API (Giao diện lập trình ứng dụng)

Phần quan trọng nhất trong JUnit là junit.framework , chứa

tất cả các lớp cốt lõi Một số các lớp quan trọng như:

Trang 27

STT Tên lớp Chức năng

class

Một tập hợp các phương pháp khẳng định

2 TestCase Xác định các vật cố định để chạy nhiều

bài kiểm tra

3 TestResult TestResult thu thập kết quả thực hiện

Trang 28

STT Phương pháp & Mô tả

1 Void assertEquals ( boolean expected, boolean

actual )

Kiểm tra xem hai đối tượng nguyên thuỷ / vật thể cóbình đẳng

2 Void assertFalse ( boolean condition )

Kiểm tra xem điều kiện nào là sai

3 Void assertNotNull ( Object object )

Kiểm tra xem một đối tượng không phải là null

4 Void assertNull ( Object object )

Kiểm tra rằng một đối tượng là null

5 Void assertTrue ( boolean condition )

Kiểm tra xem điều kiện nào là đúng

6 Void fail ()

Kiểm tra thất bại mà không thông báo

Trang 29

Hãy sử dụng một số phương pháp nêu trên trong một ví

dụ Tạo tệp tin lớp java có tên TestJunit1.java trong C: \> JUNIT_WORKSPACE

import org.junit.Test;

import static org.junit.Assert.*;

public class TestJunit1 {

@Test

public void testAdd() {

//test data

int num = 5;

String temp = null;

String str = "Junit is working fine";

//check for equality

assertEquals("Junit is working fine", str);

//check for false condition

assertFalse(num > 6);

Trang 30

//check for not null value

assertNotNull(str);

}

}

Tiếp theo, tạo tệp tin lớp java có tên TestRunner1.java trong

C: \> JUNIT_WORKSPACE để thực hiện (các) trường hợp kiểmtra

import org.junit.runner.JUnitCore;

import org.junit.runner.Result;

import org.junit.runner.notification.Failure;

public class TestRunner1 {

public static void main(String[] args) {

Result result = JUnitCore.runClasses(TestJunit1.class);

for (Failure failure : result.getFailures()) {

System.out.println(failure.toString());

}

Trang 31

System.out.println(result.wasSuccessful());

}

}

Biên dịch các trường hợp thử nghiệm và các lớp Runner thửnghiệm bằng cách sử dụng javac

C:\JUNIT_WORKSPACE>javac TestJunit1.java TestRunner1.java

Bây giờ chạy Runner thử nghiệm, mà sẽ chạy các trường hợpthử nghiệm được xác định trong các lớp Test Case được cungcấp

của lớp TestCase như sau:

Ngày đăng: 21/11/2017, 14:43

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w