Kiểm thử đơn vị với nunit

Mục lục

Lời nói đầu
Ngày nay máy tính đã đóng một vai trò quan trọng trong cuộc sống của chúng ta
Máy tính khác những máy móc thông thường khác ở chỗ nó có thể thực hiện nhiều nhiệm
vụ khác nhau bằng cách sử dụng phần mềm .Tức là phần mềm có thể quyết định năng lực
của máy tính.Trong những năm đầu của ngành công nghiệp máy tính, người ta chú trọng
phát triển về phần cứng nhằm mục đích giảm giá thành hệ thống , tăng khả năng vận
chuyển và lưu trữ dữ liệu .Vai trò của phần cứng là quan trọng hơn so với phần
mềm.Phần mềm thường được cho không hoặc đi kèm với máy khi bán.Tuy nhiên trong từ
những năm 90 trở lại đây nhu cầu về phần mềm đã tăng lên nhanh chóng mục tiêu của
ngành công nghiệp máy tính là cải thiện và giảm giá thành phần mềm .Vai trò của phần
mềm đã trở nên quan trọng hơn. Nhiều khi giá thành phần mềm đắt hơn cả giá cả của
thiết bị phần cứng.
Và khi phần mềm đã ngày càng trở nên quan trọng hơn thì một chuyên ngành một
lĩnh vực dành riêng cho phần mềm là không thể thiếu. Công nghệ phần mềm đã ra đời
nhằm nâng cao và kiểm soát chất lượng phần mềm. Song song với việc thiết kế ra một
phần mềm chất lượng thì trong quá trình làm ra một sản phẩm phần mềm còn có rất nhiều
các công việc khác như quản lý dự án để tinh toán chi tiết tài nguyên, thời gian, chi phí để
đạt dược lợi ích tối đa, quản lý rủi ro để giảm thiểu những vấn đề khó khăn trong quá
trình thiết kế phần mềm và một hoạt động khá quan trọng luôn đi kèm trong quá trình
thiết kế đó là kiểm thử phần mềm. Hiện nay có khoảng năm phương pháp kiểm thử phần
mềm đó là kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận,
kiểm thử hệ thống nhúng.
Trong đó kiểm thử đơn vị là kiểm thử riêng lẻ các module. Cũng có nhiều công cụ
đã được xậy dựng để hỗ trợ kiểm thử đơn vị và kiểm thử tích hợp như JUnit được viết
1


bằng Java dùng để kiểm thử cho các chương trình được viết bằng ngôn ngữ lập trình Java
và .Net cũng có các công cụ của mình như xUnit, NUnit và với đề tài “Kiểm thử đơn vị

với Nunit” chúng tôi sẽ giới thiệu cho các bạn cách kiểm thử đơn vị với công cụ NUnit
và ngôn ngữ lập trình C#.

Phần 1: Kiểm thử phần mềm
I.Khái niệm kiểm thử phần mềm
- Kiểm thử phần mềm có nhiều cách định nghĩa khác nhau. Tuy nhiên, chúng cùng
bao trùm hai nội dung cơ bản là phát hiện lỗi và đánh giá chất lượng của phần mềm. Định
nghĩa sau đây của Myers là đơn giản và có tính thực tế: “Kiểm thử là tiến trình thực thi
chương trình với mục đích tìm thấy lỗi”. Theo định nghĩa của Myers, kiểm thử mà không
phát hiện được lỗi được coi là không thành công.
-Mục đích của kiểm thử là phát hiện lỗi vì trong thực tế phần mềm hầu như không
bao giờ không chứa lỗi.

II. Kỹ thuật kiểm thử phần mềm
-Kỹ thuật kiểm thử có thể được chia làm 2 loại: kỹ thuật kiểm thử chức
năng(Functional Testing) hay còn gọi là kiểm thử hộp đen(Black-Box Testing) và kỹ
thuật kiểm thử cấu trúc(Structural Testing ) hay còn gọi là kiểm thử hộp trắng (WhiteBox Testing).

1.Kỹ thuật kiểm thử chức năng
-Trong kỹ thuật kiểm thử chức năng dữ liệu kiểm thử được xuất phát từ đặc tả
phần mềm bao gồm: đặc tả các yêu cầu(đối với kiểm thử hệ thống), đặc tả thiết kế(đối
với kiểm thử tích hợp) và đặc tả chi tiết mô-đun với (kiểm thử đơn vị). Trong kỹ thuật
này, kiểm thử viên xem phần mềm như là một hộp den, kiểm thử viên không quan tâm tới
cấu trúc và hành vi bên trong phần mềm. Kiểm thử viên chỉ quan tâm tới việc tìm các
hiện tượng mà phần mềm hoạt động không đúng với đặc tả của nó. Kiểm thử viên chỉ
biết những gì dự kiến thực hiện và những gì dự kiến không thực hiện, mà không thể nhìn
bên trong xem nó hoạt động như thế nào. Vì thế dữ liệu kiểm thử sẽ xuất phát từ đặc tả.
-Kiểm thử chức năng cố gắng tìm ra những lỗi sau: thiếu chức năng, lỗi giao diện,
lỗi cấu trúc dữ liệu, lỗi truy cập cơ sở dữ liệu, lỗi thi hành, lỗi khởi tạo hoặc kết thúc…
2

2.Kỹ thuật kiểm thử cấu trúc.
- Kỹ thuật kiểm thử cấu trúc là kỹ thuật dựa trên sự phân tích mã chương trình
hoặc một mô hình của mã chương trình để xây dựng các phép thử theo các tiêu chuẩn bao
phủ.
-Kỹ thuật kiểm thử cấu trúc cho phép chúng ta kiểm thử cấu trúc bên trong của
phần mềm, với mục đích kiểm tra tất cả các câu lệnh và điều kiện tồn tại trong phần mềm
đó. Trong kỹ thuật này kiểm thử viên lấy dữ liệu thử xuất phát từ việc kiểm tra logic của
chương trình (không quan tâm đến đặc tả).

III. Chiến lược kiểm thử
1.Khái niệm
-Một chiến lược kiểm thử (test strategy) là một kế hoạch định nghĩa mục tiêu các
giai đoạn kiểm thử cũng như các kỹ thuật kiểm thử sử dụng. Chiến lược kiểm thử thường
được quyết định dựa vào tiêu chuẩn về độ tin cậy của phần mềm và chi phí cho việc phát
triển phần mềm. Ngoài ra, một chiến lược kiểm thử sẽ phụ thuộc kích thước của đối
tượng được kiểm thử cũng như quan điểm về đối tượng được kiểm thử.
-Nếu chúng ta muốn kiểm thử một cách độc lập các thành phần/đơn vị cấu tạo nên
phần mềm, chúng ta gọi là kiểm thử đơn vị. Nếu chúng ta muốn kiểm thử sự kết hợp các
thành phần cấu tạo nên phần mềm, chúng ta gọi là kiểm thử tích hợp. Nếu chúng ta muốn
bảo đảm rằng một phần mềm đang được phát triển một cách đúng đắn và các thành phần
cấu tạo nên phần mềm cũng được phát triển một cách đúng đắn, chúng ta gọi là xác minh
(verification). Tuy nhiên, một phần mềm không chỉ đơn thuần là đáp ứng yêu cầu của nhà
sản xuất, mà nó chỉ trở nên hữu ích nếu đáp ứng được nhu cầu của người sử dụng cuối
cùng. Việc bảo đảm một phần mềm đáp ứng nhu cầu của người sử dụng được gọi là hợp
thức hoá (validation).

2. Một số chiến lược Kiểm Thử
2.1 Kiểm thử từ trên xuống(Top-Down)

-Chiến lược kiểm thử tích hợp Top Down - từ trên xuống là một cách tiện lợi
đểxây dựng và kiểm soát cấu trúc chương trình. Chiến lược này gộp dần các module từ
trên xuống theo trật tự dòng điều khiển, bắt đầu từ module điều khiển chính gắn từng
module phụ trợ vào module điều khiển thượng cấp.
-Có thể theo 2 cách: Theo chiều sâu, theo chiều rộng.
-Tích hợp từ trên xuống thực hiện theo 6 bước:
3


1. Module điều khiển chính được dùng như bộ lái kiểm thử (test driver) và các module
phụ trợ trực tiếp được thay thế bởi các cuống (stub)
2.Thay thế dần từng cuống bởi module thực thi tương ứng.
3.Sau khi tích hợp module đó tiến hành kiểm thử tương ứng]
4. Khi hoàn thành các kiểm thử này thì thay một cuống khác bằng module thực (nghĩa là
quay lại bước 2).
5.Các thể kiểm thử lại ( toàn bộ hoặc toàn bộ các kiểm thử trước – kiểm thử hồi quy) để
đảm bảo rằng không có sai nào mới được xảy ra.
6.Tiếp tục lặp lại từ bước 2 cho tới khi toàn bộ cấu trúc chương trình được xây dựng

2.2 Kiểm thử từ dưới lên(Bottom-Up)
-Chiến lược kiểm thử tích hợp Bottom Up – từ dưới lên bắt đầu xây dựng và kiểm thử
từ các module nguyên tố: việc xử lý nếu có đòi hỏi các module phụ trợ thì các module
thực sự đã sẵn sàng (cuống đã bị loại).
-Thực hiện theo 4 bước:
1. Các module mức thấp được tổ hợp trong các cụm (cluster) thực hiện một chức năng
phụ trợ đặc biệt.
2. Một bộ lái được viết để phối hợp đầu vào và đầu ra của ca kiểm thử.
3. Kiểm thử cụm đó
4. Tháo bỏ các driver & cụm tổ hợp ngược lên trong cấu trúc chương trình
4

2.3 Kiểm thử vụ nổ lớn(Bigbag)
-Kết hợp tất cả các module đã kiểm thử đơn vị thành chương trình tiến hành kiểm
thử toàn bộ chương trình 1 lúc. Kết quả ta được 1 mớ hỗn độn với 1 tập các sai, chỉnh sửa
chúng là khó khăn vì cô lập các nguyên nhân là phức tạp: sai này có thể sửa nhưng lại
xuất hiện nhiều sai khác, cứ thế triền miên!
2.4 Kiểm thử hồi quy (Regression Test)
-Kiểm thử hồi quy không phải là một mức kiểm tra như các mức khác nói trên. Nó
đơn thuần kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên
bản phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không
gây ra lỗi mới trên những chức năng đã hoạt động tốt. Kiểm thử hồi quy có thể thực hiện
tại mọi mức kiểm tra.

VI. Các giai đoạn kiểm thử
1.Kiểm thử đơn vị
-Kiểm thử đơn vị :là tiến trình kiểm thử tập trung vào các đơn vị nhỏ nhất của thiết kế
phần mềm đó là hàm, các lớp, các thủ tục hoặc các phương thức. Kiểm thử đơn vị bao
giờ cũng hướng theo hộp trắng và bước này có thể được tiến hành song song cho nhiều
môđun.
-Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn
giản nên không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả.
Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ
khoanh vùng một đơn thể đơn vị đang kiểm tra. Thời gian tốn cho Unit Test sẽ được đền
5


bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các
mức độ kiểm tra sau đó.
-Unit Test thường do lập trình viên thực hiện. Công đoạn này được thực hiện cùng với

giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.
-Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình
huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực
hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử
dụng.

2. Kiểm thử tích hợp
-Kiểm thử tích hợp – Integrating Test nhằm nhận được bộ phận chức năng hay hệ con
tốt là một kỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình.
-Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng
dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì
Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
-Integration Test có 2 mục tiêu chính:
Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ
thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).
-Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu
trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các
thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm
tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.
-Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được
kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa.
Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả
lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit
dẫn đến những tình huống hoàn toàn khác.
-Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.
Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước
đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử
giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm
cho số lượng kiểm thử sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

6


3. Kiểm thử mức hệ thống (System Test)
-Mục đích của kiểm tra hệ thống là kiểm tra thiết kế và toàn bộ hệ thống sau khi tích
hợp có thỏa mãn yêu cầu đặt ra hay không.
Có 2 cách :
-Kiểm thử Alpha
+Được bên phát triển tiến hành
+Phần mềm sẽ được dùng trong bối cảnh tự nhiên để người phát triển đứng vào vai
trò người sử dụng và báo cáo các sai và các vấn đề sử dụng
+Được tiến hành trong một môi trường được điều khiển (theo kế hoạch của người
phát triển)
-Kiểm thử Beta
+Được một hay nhiều người đặt hàng tiến hành
+Không có sự hiện diện người phát triển
+Áp dụng phần mềm trong môi trường thực, không có sự kiểm soát của người phát
triển
+Khách hàng sẽ báo cáo tất cả các vấn đề mà họ gặp trong quá trình kiểm thử cho
người phát triển một cách định kỳ
+Dựa theo báo cáo đó người phát triển tiến hành sửa đổi và chuẩn bị phân phối bản
phát hành cho toàn bộ các người đặt hàng

4. Kiểm thử chấp nhận phần mềm (Acceptance Test)
Kiểm thử chấp nhận được khách hàng thực hiện. Mục đích của kiểm thử chấp nhận
là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp
nhận sản phẩm chưa.
Kiểm thử chấp nhận có ý nghĩa quan trọng, mặc dù hầu hết mọi trường hợp, các
phép kiểm tra của kiểm thử hệ thống và kiểm thử chấp nhận gần tương tự như nhau,
nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình
phát triển phần mềm thì kết quả của kiểm thử chấp nhận sẽ sai lệch rất lớn, mặc dù phần
mềm đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai
yêu cầu và sự mong chờ của khách hàng

V. Một số vấn đề khác của kiểm thử phần mềm
1. Các hạn chế của kiểm thử
-Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định
tính đúng của chương trình do bản chất quy nạp không hoàn toàn của nó.
7


-Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn
đầu của quá trình cài đặt sản phẩm.
-Một chương trình được cho tuyệt đối đúng phải được thực hiện thông qua: tính đúng
đắn của thuật toán và tính tương đương của chương trình với thuật toán (được thể hiện ở
chứng minh thông qua văn bản chương trình).
-Việc kiểm thử chương trình chỉ là nhìn sự kiện đưa ra kết luận do vậy không thể
khẳng định một chương trình tuyệt đối đúng bằng kiểm thử. Tuy vậy, bộ dữ liệu kiểm thử
phải phủ kín mọi trường hợp cần đánh giá.
-Thêm vào đó, trong quá trình kiểm thử, ta thường mắc phải các đặc trưng của nguyên
lý chủ quan như sau:
+ Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm.
+ Chỉ kiểm thử các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các
sự cố.
+ Cài đặt chức năng nào thì chỉ kiểm thử riêng chức năng đó, không kiểm thử tổng hợp
chức năng vừa cài đặt với các chức năng đã cài đặt trước đó.
+ Người kiểm thử cũng đồng thời là người xây dựng phần mềm

2. Các nguyên tắc kiểm thử

-Các nguyên tắc luôn đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm.
Các nguyên tắc trong công nghệ phần mềm là các luật hay quy tắc hướng dẫn làm thế nào
để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm. Kiểm thử là một trong
những lĩnh vực của công nghệ phần mềm, kiểm thử cũng có các nguyên tắc riêng dành
cho các kiểm thử viên. Chúng ta sẽ xem xét một số nguyên tắc cơ bản liên quan đến kiểm
thử động:
- Kiểm thử là tiến trình thực thi phần mềm và sử dụng các trường hợp kiểm thử để
phát hiện lỗi.
- Với mục đích của kiểm thử nhằm phát hiện lỗi, một ca kiểm thử tốt là ca kiểm
thử có khả năng cao phát hiện những lỗi chưa được tìm thấy.
- Một ca kiểm thử phải định nghĩa kết quả mong muốn.
- Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển.
- Kết quả kiểm thử nên được kiểm tra một cách cẩn thận.
8


- Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào hợp lệ và không hợp
lệ.
- Các ca kiểm thử phải được tái sử dụng.
- Xác suất tồn tại của các lỗi hơn nữa trong một đơn vị phần mềm tỷ lệ với số các
lỗi đã được phát hiện trong đơn vị phần mềm đó.
- Kiểm thử nên phải được lập kế hoạch.
- Các hoạt động kiểm thử nên phải được tích hợp vào tiến trình phát triển phần
mềm.
- Kiểm thử là một công việc đầy sáng tạo và thách thức

Phần 2: Giới thiệu công cụ Nunit
I.Giới thiệu
-NUnit là một framework kiểm thử đơn vị cho tất cả ngôn ngữ .Net. Ban đầu được
chuyển từ JUnit (framework kiểm thử đơn vị của Java) , việc phát hành sản xuất hiện

nay, phiên bản 2.5, là bản phát hành lớn thứ sáu của công cụ này dựa xUnit kiểm tra đơn
vị cho Microsoft. NET. Nó được viết hoàn toàn bằng C # và đã hoàn toàn được thiết kế
lại để tận dụng lợi thế của nhiều tính năng ngôn ngữ .NET, ví dụ cho các thuộc tính tùy
9


chỉnh và phản ánh khả năng khác có liên quan. NUnit mang xUnit tới tất cả các ngôn ngữ
.NET.

II. Assertion
-Lớp Assert là trung tâm để test trong NUnit. NUnit cung cấp một tập phong phú của
khẳng định là phương pháp tĩnh của lớp Assert. Nếu một khẳng định thất bại, sẽ có lỗi
được báo cáo. Nếu một thử nghiệm chứa nhiều khẳng định, bất kỳ một trong những
khẳng định đó thất bại các khẳng định sau sẽ không được thi hành. Vì lý do này, nó
thường là tốt nhất để thử cho một khẳng định cho mỗi bài kiểm tra. Mỗi cách đều có thể
được gọi là không có một tin nhắn, với một tin nhắn văn bản đơn giản hay với một tin
nhắn và các đối số. Trong trường hợp cuối bài viết được định dạng bằng văn bản cung
cấp và đối số. Trước khi hai kiểu xe 2,4 NUnit, một phương pháp riêng biệt của lớp
Khẳng định đã được sử dụng cho từng khẳng định khác nhau. Chúng tôi gọi đây là "cổ
điển Model." Nó tiếp tục được hỗ trợ trong NUnit, vì nhiều người thích nó. Bắt đầu với
2,4 NUnit, một "Hạn chế mới dựa trên" mô hình đã được giới thiệu. Phương pháp này sử
dụng một phương pháp duy nhất của lớp Khẳng định cho tất cả khẳng định, đi qua một
đối tượng mà xác định Hạn chế kiểm tra được thực hiện. Điều này hạn chế dựa trên mô
hình bây giờ là được sử dụng trong nội bộ của NUnit cho tất cả khẳng định. Các phương
pháp của các phương pháp cổ điển đã được tái triển khai thực hiện trên mô hình mới.

1 Các phương thức Equal Assert – Khẳng định ngang bằng

10

-Những phương thức này kiểm tra xem hai đối số là bằng nhau. Phương thức này
được nạp chồng cho các loại giá trị phổ biến để các ngôn ngữ mà không tự động các giá
trị hộp có thể sử dụng chúng trực tiếp.
Assert.AreEqual(type expected, type actual)
Assert.AreNotEqual(type expected, type actual)
-So sánh các loại giá trị số khác nhau Các phương thức này được nạp chồng so sánh
hai đối giá trị số của các loại khác nhau so sánh. Kết quả của lệnh so sánh này là đúng:
Assert.AreEqual (5, 5,0);
-So sánh Mảng và Tuyển tập đối tượng:
-Kể từ phiên bản 2.2, NUnit có thể so sánh hai mảng 1 chiều. Bắt đầu với phiên bản
2.4, mảng đa chiều, mảng lồng nhau (mảng của mảng) và tuyển tập đối tượng có thể được
so sánh. Hai mảng hoặc các Tuyển tập đối tượng sẽ được coi như là bằng nhau bởi
Assert.AreEqual nếu họ có kích thước tương tự và nếu mỗi yếu tố tương ứng là bằng
nhau.

2 Identity Assert – Khẳng định xác nhận
-Assert.AreSame và Assert.AreNotSame so sánh 2 đối tượng truyền vào có cùng kiểu
hay không.
Assert.AreSame( object expected, object actual );
Assert.AreSame( object expected, object actual, string message );
Assert.AreSame( object expected, object actual, string message,
params object[] parms );
Assert.AreNotSame( object expected, object actual );
Assert.AreNotSame( object expected, object actual, string message );
Assert.AreNotSame( object expected, object actual, string message,
params object[] parms );
-Assert.Contains kiểm tra 1 đối tượng có được chứa trong 1 mảng hay 1 tuyển tập
hay không
Assert.Contains( object anObject, IList collection );

Assert.Contains( object anObject, IList collection,
string message );
Assert.Contains( object anObject, IList collection,
string message, params object[] parms );

3.Condition Assert – Khẳng định điều kiện

11


-Phương thức này test một điều kiện cụ thể được đặt tên theo các điều kiện mà họ
kiểm tra và lấy giá trị thử nghiệm là đối số đầu tiên, và tùy chọn một tin nhắn ở đối số thứ
hai. Các phương pháp sau đây được cung cấp:
Assert.IsTrue( bool condition );
Assert.True( bool condition );
Assert.IsFalse( bool condition);
Assert.False( bool condition);
Assert.IsNull( object anObject );
Assert.Null( object anObject );
Assert.IsNotNull( object anObject );
Assert.NotNull( object anObject );
Assert.IsNaN( double aDouble );
Assert.IsEmpty( ICollection collection );
Assert.IsNotEmpty( ICollection collection );
-Ở đây ta thấy có 2 dạng khẳng định IsXXX và không XXX. Phương thức IsXXX
dùng cho phiên bản cũ còn XXX thích hợp cho cả bản NUnitLite

4 Comparisions Assert – Khẳng định so sánh
-Các phương thức này so sánh giá trị 2 tham số truyền vào bao gồm so sánh >, >=, < ,
<= tương ứng với các phương thức

Assert.Greater( type arg1, type arg2 );
Assert.GreaterOrEqual(type arg1, type arg2 );
Assert.LessOrEqual(type arg1, type arg2 );
Assert.LessOrEqual(type arg1, type arg2 );

5 Type Assert – Khẳng định kiểu
-Các phương thức này kiểm tra xem 1 đối tượng có đúng kiểu mong muốn hay không
Assert.IsInstanceOfType( Type expected, object actual );
Assert.IsNotInstanceOfType( Type expected, object actual );
Assert.IsAssignableFrom( Type expected, object actual );
Assert.IsNotAssignableFrom( Type expected, object actual );

III.Attributes - Các thuộc tính
1TestFixture
-Đây là thuộc tính đánh dấu một lớp có chứa các test case và tùy chọn hoặc cài đặt các
phương thức teardown. NUnit 2.5 giới thiệu các tham số kiểm tra chung - xem dưới đây.
Hầu hết các hạn chế về một lớp đều được sử dụng cho lớp testfixture hiện nay đã được
loại bỏ. Với NUnit 2.5.3, lắp thử nghiệm lớp:
* Có thể là public, protected, private, internal.
12


* Có thể một lớp static trong NET 2.0
* Có thể kế thừa
* Có thể không được trừu tượng - dù thuộc tính có thể được áp dụng cho một lớp trừu
tượng dùng để phục vụ như là một lớp cơ sở testfixture.
* Nếu không có đối số được cung cấp với TestFixtureAttribute, các lớp phải có một
constructor mặc định.
* Nếu đối số được cung cấp, chúng phải phù hợp với một trong những constructor.
Nếu một trong những hạn chế này bị vi phạm, lớp test không thể chạy và sẽ hiển thị một

lỗi.
-Bắt đầu với NUnit 2.5, thuộc tính TestFixture có thể tùy chọn không tham số, Vì vậy,
miễn là lớp có chứa ít nhất một phương pháp đánh dấu bằng thuộc tính Test, TestCase
hoặc TestCaseSource, nó sẽ được coi như là một lớp thử nghiệm.
namespace NUnit.Tests
{
using System;
using NUnit.Framework;
[TestFixture]
public class SuccessTests
{
// ...
}
}

2 TearDown
-Thuộc tính này được sử dụng trong một TestFixture để cung cấp một tập lệnh được
thực hiện sau khi mỗi phương thức test được chạy.
-Trước NUnit 2.5, một TestFixture chỉ có thể một phương thức TearDown và nó
được yêu cầu phải có một phương thức ví dụ.
-Bắt đầu với NUnit 2.5, TearDown có thể là tĩnh hoặc các phương thức ví dụ và bạn
có thể định nghĩa nhiều hơn một Teardown trong một Testfixture. Bình thường, nhiều
13


phương pháp TearDown chỉ được xác định ở các cấp độ khác nhau của một hệ thống
phân cấp thừa kế, như được giải thích dưới đây.
-Vì vậy, miễn là bất kỳ phương thức Setup chạy mà không có lỗi, phương thức
TearDown được đảm bảo để chạy. Nó sẽ không chạy nếu một phương thức Setup lỗi
hoặc ném một ngoại lệ.

namespace NUnit.Tests
{
using System;
using NUnit.Framework;
[TestFixture]
public class SuccessTests
{
[SetUp] public void Init()
{ /* ... */ }
[TearDown] public void Cleanup()
{ /* ... */ }
[Test] public void Add()
{ /* ... */ }
}

3 Setup
Ngược với Teardown phương thức Setup là đề cài đặt một tập lệnh trước khi phương
thức test được chạy

4 Test
-Thuộc tính kiểm tra là một cách để đánh dấu một phương thức bên trong một lớp
TestFixture như một ca kiểm thử. Đối với khả năng tương thích ngược với các phiên bản
trước của Nunit một phương thức test cũng có thể được tìm thấy nếu 4 chữ cái đầu tiên là
"Test" bất kể trường hợp. Tùy chọn này có sẵn bằng cách thiết lập một giá trị trong file
cấu hình để test.
-Trước khi đến 2,5 NUnit, chữ ký cho một phương pháp thử nghiệm là:
public void methodName ()
-Bắt đầu với NUnit 2.5, phương thức tĩnh có thể được sử dụng làm các test:
public void methodName ()
14

-Ngoài ra, với 2.5, phương test có thể có đối số và giá trị trả về
namespace NUnit.Tests
{
using System;
using NUnit.Framework;
[TestFixture]
public class SuccessTests
{
[Test] public void Add()
{ /* ... */ }
public void TestSubtract()
{ /* backwards compatibility */ }
}
}

5 TestCase
-Thuộc tính TestCase phục vụ mục đích đánh dấu một phương thức test với các
tham số như là một phương pháp thử nghiệm và cung cấp dữ liệu nội tuyến sẽ được sử
dụng khi gọi phương thức. Dưới đây là một ví dụ về một bài kiểm tra đang được chạy ba
lần, với ba bộ khác nhau của dữ liệu:
[TestCase(12,3,4)]
[TestCase(12,2,6)]
[TestCase(12,4,3)]
public void DivideTest(int n, int d, int q)
{
Assert.AreEqual( q, n / d );
}

IV.Cài đặt
-Sau khi chạy bộ setup như các ứng dụng bình thường chúng ta phải config Nunit
vào Visual Studio hoặc các bộ IDE rời như Visual C#
Và chúng tôi lấy Visual C# 2008 làm ví dụ:
15


Mở Visual C# 2008 vào Tool/External Tools

-Trong bảng External Tools đặt các thông số như hình với Command là đường dẫn
tới file nunit.exe , title có thể đặt tùy

V. Sử dụng

16


-Ta có thể tạo bất cứ kiểu project nào trong Visual Studio hoặc Visual C# để tiến
hành test. Trong project đó sẽ có các lớp do ta thiết kế như bình thường và kèm theo các
lớp dùng để test. Để làm được điều đó trước hết ta phải
Add Reference cho Project tới Nunit Framework:
Chuột phải vào References của Project\Add Reference
-Trong bảng Add Reference chọn nunit.framework

-Để tạo file test ta khai báo namespace NUnit.Framework bằng câu lệnh using
NUnit.Framework;
-Sau đó ta tạo ra các class dùng để test và trước 1 lớp test ta khai báo từ khóa
[TextFixture]
Ví dụ:
[TestFixture]

17


public class TestClass{}
Trong lớp này tao phải tao ra các phương thức test để test các module hay các phương
thức trong chương trình ta muốn test trước các lớp này ta khai báo từ khóa [Test]
Ví dụ:
[Test]
public void Test(){}
Sau đó chúng ta debug project(F5) sau đó vào Tool và chạy tool ban đầu chúng ta
tạo ra chương trình Nunit sẽ tự động khởi chạy và chạy class test của chúng ta.
Chúng ta có thể tạo riêng 1 project để test 1 project khác khi đó chúng ta phải add
reference cho project này tới project muốn test và trong file cs chúng ta phải khai báo
namespace chứ lớp hay module muốn test trong project đó. Thường thì test project này
được để là kiểu Class Library khi debug(F5) kiểu project này sẽ có báo lỗi nhưng ta vẫn
chạy tool Nunit như bình thường.

Phần 3:Chương trình kiểm thử đơn vị với
NUnit

18