Slide Test driven development

LOGO
Các vấn đề hiện đại của Công nghệ phần mềm
Test-driven Development
Test-driven Development
Nhóm 8
Giảng viên: TS. Võ Đình Hiếu
Thành viên nhóm:
Nguyễn Thị Ánh
Phạm Anh Đạt (Nhóm trưởng)
Nguyễn Thị Loan
Test-driven Development
Nội dung
Định nghĩa
Tại sao một PM nên phát triển theo hướng TDD?
Chu trình phát triển
Thuận lợi và thách thức
Định hướng phát triển
2
Các khung kiểm thử của TDD
Demo

Traditional development cycle

Test-driven development cycle
Test-driven Development
3
Test-driven Development
Định nghĩa

TDD là phương pháp tiếp cận cải tiến phát triển PM dựa trên sự lặp lại
của một chu kỳ phát triển:


Viết một automated test case xác định một cải thiện mong muốn hoặc một
chức năng mới.

Tạo ra một lượng chỉ vừa đủ code để vượt qua test case đó.

Cấu trúc lại mã mới với các tiêu chuẩn chấp nhận được.
4
TDD
TDD
Test first
Development
Test first
Development
Refactoring
Refactoring
Test-driven Development
Test-driven Development
5
Phần mềm nên phát triển theo hướng TDD?

TDD và cách kiểm thử truyền thống
Test-driven Development
6
Kiểm thử truyền thống TDD

Một mẫu kiểm thử thành công sẽ tìm ra một
hoặc nhiều lỗi.

Hệ thống càng có nhiều rủi ro lớn càng cần

phải có nhiều mẫu kiểm thử được thực hiện.

Khi một mẫu kiểm thử thất bại bạn biết rằng
bạn cần phải giải quyết một số vấn đề.

Đạt được 100% khi kiểm thử độ phủ mã
nguồn (coverage test) - mọi dòng mã đều
được kiểm thử.
Phần mềm nên phát triển theo hướng TDD?

TDD là một kỹ thuật đặc tả, đem lại kết quả trong việc kiểm thử mã nguồn tốt
hơn đáng kể so với các kỹ thuật truyền thống.

TDD tăng niềm tin hệ thống của bạn đáp ứng được các yêu cầu, hệ thống của
bạn đang hoạt động và có thể tiếp tục.

Một lợi thế đáng kể của TDD là nó cho phép bạn thực hiện các bước nhỏ khi
viết phần mềm.
Test-driven Development
7

Nhiều người cho rằng các kỹ thuật Agile hoạt động rất ổn với những dự án nhỏ, cần một số ít người trong
một vài tháng, nhưng chúng không hoạt động đối với những dự án thực sự lớn hơn. Tuy nhiên, điều đó
không hoàn toàn đúng.

Ví dụ: một hệ thống Smalltalk
–
TDD
•
4 năm, 40 man-year

•
250,000 function code lines; 25000 test code lines
•
4000 test case: ~ 20 min
–
Bộ kiểm thử đầy đủ: ~ vài ngày

TDD vẫn hoạt động tốt với những dự án có kích thước lớn.
Test-driven Development
8
Phần mềm nên phát triển theo hướng TDD?
Chu trình phát triển
Test-driven Development
9
Add a test

Mỗi tính năng mới bắt đầu bằng
cách viết một test.

Test này chắc chắn phải thất bại vì
nó được viết trước khi tính năng
được thực hiện.

Để viết một test, phải hiểu rõ đặc
tả yêu cầu của tính năng này.
Test-driven Development
10
Run all tests and see if the new one
fails


Điều này xác nhận rằng test
đang làm việc một cách chính
xác và các test mới không pass
nhầm mà không cần bất kỳ code
mới nào.

Bước này cũng kiểm thử chính
các test.
Test-driven Development
11
Write some code

Viết một số mã để pass. Mã mới
được viết trong giai đoạn này là
không hoàn hảo. Điều đó là chấp
nhận được vì các bước sau sẽ cải
thiện nó.

Tại thời điểm này, mục đích duy
nhất của các mã được viết là phải
vượt qua các test.
Test-driven Development
12
Run tests

Nếu tất cả các test cases đều
pass, lập trình viên có thể tự tin
rằng code đã đáp ứng được tất
cả các yêu cầu.
Test-driven Development

13
Refactor code

Quá trình làm thay đổi code hiện
có mà không cần thay đổi hành vi
bên ngoài của nó.

Có sự trùng lặp.

Thấy rằng code và/hoặc mục đích
của nó không rõ ràng.

Cảm thấy code có vấn đề.
Test-driven Development
14
Repeat

Bắt đầu với một test mới, chu kỳ
sau đó được lặp đi lặp lại để hoàn
thiện các chức năng.
Test-driven Development
15
Test-driven Development
Ưu điểm

Chất lượng

Hiệu quả

Xác định đúng chức năng


Hạn chế các lỗi bên trong

Giảm bớt sự thay đổi

Tài liệu cho nhà phát triển

Lập trình viên được làm chủ
16
Ưu điểm

Chất lượng

Chất lượng trên nhiều khía cạnh : thiết kế hướng dẫn, định hướng

Tiêu chí : gán chất lượng với số lỗi tìm ra sau khi sử dụng phần mềm, chi phí bảo trì.

Tất cả các chức năng được cài đặt đều có giá trị

Kỹ năng test : hỗ trợ giao diện cho các modules, class, những gì bạn có và được đảm
bảo bởi QA

Giảm thời gian cho fix lỗi : fix các lỗi tốn hơn 40 lần so với việc viết code mới => test
làm mịn + liên tục chạy test
Test-driven Development
17
Test-driven Development
Ưu điểm
Phát hiện lỗi theo
Từng bước nhỏ.

design
test
implement
test
Phát hiện lỗi sớm hơn,
Tìm lỗi dễ hơn
Viết test đầu tiên
Cài đặt code theo các testcase
Xác định chức năng
18
Ưu điểm

Xác định đúng chức năng

Nhu cầu trao đổi để xác định chức năng là bắt buộc định hình ý tưởng thiết kế

Các lập trình viên được chủ động

Không ai đảm bảo một hệ thống có nhiều nguy cơ “We don’t touch that, it might break!”

Các lập trình viên có thể làm mọi thứ trên code của mình miễn là code đấy test pass

Với một test hoàn thành : nếu
•
Test fails, bạn biết bạn đã phá vỡ cái gì đó
•
Test pass, không cần phải làm gì nữa
Test-driven Development
19
Ưu điểm


Tài liệu cho các nhà phát triển:

Các test mô tả sự hiểu biết của bạn về chức năng đó của dự án

Việc thêm một vài comment trước mỗi test là bạn đã có một tài liệu hướng dẫn cho các nhà phát triển
khác .

Giảm bớt sự thay đổi

Thêm chức năng

Yêu cầu mới

Cấu trúc lại
Test-driven Development
20
TDD cho các công nghệ phát triển

Với các thành phần web

Java Servlets
•
Hai đối tượng HttpServletRequest đại diện request HTTP đóng gói các thông tin cần thiết và HttpServletResponse là
cổng tạo ra phản ứng cho phía client.
•
Làm thế nào test với hoạt động 2 đối tượng này ?
=> Tạo các request và response giả mạo
•
Muốn test Servlet trước cần xác minh rằng nó thực sự tạo các response dự kiến.

•
Chúng ta phải cung cấp các trường hợp mà HttpServletRequest và HttpServletResponse có thể gọi với một cặp test
có sẵn của bên thứ ba
Test-driven Development
21
TDD cho các công nghệ phát triển

Java Servlet
Chúng ta mô phỏng một request
public class TestLoginServlet {
@Test
public void wrongPasswordShouldRedirectToErrorPage()
throws Exception {
HttpServlet servlet = new LoginServlet();
MockHttpServletRequest request = create fake request
new MockHttpServletRequest("GET", "/login");
request.addParameter("j_username", "nosuchuser");
request.addParameter("j_password", "wrongpassword");
MockHttpServletResponse response =
new MockHttpServletResponse(); fake response object
servlet.service(request, response);
assertEquals("/invalidlogin", response.getRedirectedUrl assert expected
Test-driven Development
22
TDD cho các công nghệ phát triển

Spring controllers

Framework Spring ứng với phần C trong mô hình MVC


Đối với một Spring Controller không chịu trách nhiệm response cho request. Thay vào đó, chúng chỉ
ra những gì mà framework có thể trả lại một đối tượng ModelAndView.
Test-driven Development
23
TDD cho các công nghệ phát triển
Spring controllers
Mô phỏng
public class SampleController implements Controller {
protected ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response)
throws Exception {
return new ModelAndView("viewname");
}
}

Các Sample sẽ ánh xạ để xử lý Các URL cụ thể.

Đối tượng request đến cổng để lấy tất cả dữliệu cần để làm bất cứ điều gì SampleController cần
để làm, và đối tượng ModelAndView trả lại nói với Spring MVC cái nhằm trả lại các response.
Test-driven Development
24
TDD cho các công nghệ phát triển

Spring controllers
Chúng ta bắt đầu viết test thứ nhất với ví dụ đăng nhập tương tự như trên với Spring MVC
public class TestLoginController {
@Test
public void wrongPasswordShouldRedirectToErrorPage()
throws Exception {
MockHttpServletRequest request =

new MockHttpServletRequest(); populate mock obj
request.addParameter("j_username", "nosuchusername");
request.addParameter("j_password", "nosuchpassword");
MockHttpServletResponse response =
new MockHttpServletResponse();
Controller c = new LoginController(); invock
ModelAndView v = c.handleRequest(request, response);
assertEquals("wrongpassword", v.getViewName()); wrongpass
}
}
Test-driven Development
25