Đang tải... (xem toàn văn)
Testdriven Development (TDD) là một kỹ thuật phát triển phần mềm dựa trên sự lặp lại của một chu kỳ phát triển: đầu tiên các nhà 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, sau đó tạo ra một lượng tối thiểu code để vượt qua test case đó, và cuối cùng cấu trúc lại mã mới với các tiêu chuẩn chấp nhận được.Phát triển dựa trên kiểm thử (TestDriven DevelopmentTDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.
NHÓM 8: TEST-DRIVEN DEVELOPMENT BÁO CÁO BÀI TẬP LỚN NGÀNH : CÔNG NGHỆ THÔNG TIN ĐỀ TÀI: TEST DRIVEN DEVELOPMENT DANH SÁCH NHÓM 8: 1.PHẠM ANH ĐẠT (Nhóm trưởng) 2.NGUYỄN THỊ LOAN 3.NGUYỄN THỊ ÁNH Hà Nội, 15/10/2013 NHÓM 8: TEST-DRIVEN DEVELOPMENT MỤC LỤC NHÓM 8: TEST-DRIVEN DEVELOPMENT NỘI DUNG CHÍNH A. LÝ THUYẾT I. Định nghĩa Test-driven Development Test-driven Development (TDD) kỹ thuật phát triển phần mềm dựa lặp lại chu kỳ phát triển: nhà phát triển viết automated test case xác định cải thiện mong muốn chức mới, sau tạo lượng tối thiểu code để vượt qua test case đó, cuối cấu trúc lại mã với tiêu chuẩn chấp nhận được. Phát triển dựa kiểm thử (Test-Driven Development-TDD) phương pháp tiếp cận cải tiến để phát triển phần mềm kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) phương pháp Điều chỉnh lại mã nguồn (Refactoring). Có quan điểm cho mục tiêu TDD đặc tả (specification) xác nhận tính đắn (validation). Nói cách khác, cách để nghĩ thiết kế bạn trước viết mã nguồn cho chức năng. Một quan điểm khác lại cho TDD kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu TDD viết mã nguồn sáng sủa, rõ ràng chạy được. TDD hoàn toàn thay đổi cách phát triển truyền thống. Khi bạn bắt đầu thực tính mới, câu hỏi đặt liệu thiết kế có phải thiết kế tốt cho phép bạn thực chức hay không. Nếu có, bạn tiến hành thông qua phương pháp Phát triển kiểm thử trước TFD. Nếu không, bạn điều chỉnh lại cách cục để thay đổi riêng phần thiết kế bị ảnh hưởng tính mới, cho phép bạn dễ dàng bổ thêm tính có thể. Kết chất lượng thiết kế bạn luôn nâng cao, thuận lợi làm việc với tương lai. NHÓM 8: TEST-DRIVEN DEVELOPMENT Một giả định TDD bạn có sẵn tảng (framework) cho kiểm thử mức đơn vị (unit-test). Những lập trình viên phần mềm theo phương pháp Agile thường sử dụng công cụ mã nguồn mở thuộc họ xUnit, JUnit hay PyUnit, công cụ thương mại lựa chọn khả dĩ. Nếu công cụ TDD thực được. Hai nguyên tắc đơn giản cho TDD: Trước tiên, bạn nên viết mã xử lý nghiệp vụ mẫu kiểm thử tự động thực không thành công. Thứ hai, bạn nên loại bỏ trùng lặp mà bạn tìm thấy. Những quy tắc đơn giản: • Bạn thiết kế với mã nguồn mà chúng chạy tạo kết phản hồi định. • Bạn viết mẫu kiểm thử cho riêng bạn bạn chờ đợi 20 lần ngày người khác viết thay bạn. • Môi trường phát triển bạn phải cung cấp kết nhanh với thay đổi nhỏ (ví dụ bạn cần trình biên dịch nhanh chuỗi kiểm thử hồi quy (regression test) • Thiết kế bạn phải bao gồm thành phần gắn kết, phụ thuộc lẫn nhỏ (loosely coupled) để thực mẫu kiểm thử dễ dàng (điều làm cho trình nâng cấp bảo trì hệ thống bạn dễ dàng hơn). II. Tại phần mềm nên phát triển theo hướng TDD? 1. TDD cách kiểm thử truyền thống TDD kỹ thuật thiết kế với hiệu ứng phụ việc đảm bảo toàn mã nguồn bạn thực kiểm thử mức đơn vị. Tuy nhiên, có điều quan trọng việc thực kiểm thử. Bạn cần xem xét kỹ thuật kiểm thử khác kiểm thử chấp nhận sản phẩm (acceptance test) hay kiểm thử dò hỏi (investigative test) theo kiểu Agile. Bạn thực nhiều kiểu kiểm thử dự án bạn chọn làm điều (và bạn nên làm). NHÓM 8: TEST-DRIVEN DEVELOPMENT Với kiểu kiểm thử truyền thống, mẫu kiểm thử thành công tìm nhiều lỗi. Tương tự với TDD, mẫu kiểm thử thất bại bạn có tiến triển bạn biết bạn cần phải giải số vấn đề. Quan trọng hơn, bạn có cách đo rõ ràng thành công mẫu kiểm thử không thất bại nữa. TDD tăng niềm tin hệ thống bạn đáp ứng yêu cầu định nghĩa cho nó, hệ thống bạn hoạt động bạn tiếp tục với tự tin. Như với thử nghiệm truyền thống, hệ thống có nhiều rủi ro lớn cần phải có nhiều mẫu kiểm thử thực hiện. Với hai kiểu kiểm thử truyền thống TDD bạn không phấn đấu cho hoàn hảo, thay vào bạn kiểm thử tầm quan trọng hệ thống. Một hiệu ứng phụ thú vị TDD bạn đạt 100% kiểm thử độ phủ mã nguồn (coverage test) - dòng mã kiểm thử - điều mà kiểm thử truyền thống không bảo đảm khuyến khích điều đó. Không có ngạc nhiên nói TDD kỹ thuật đặc tả (specification technique), với tác dụng phụ có giá trị đem lại kết việc kiểm thử mã nguồn tốt đáng kể so với kỹ thuật truyền thống. 2. Tại dùng TDD? Một lợi đáng kể TDD cho phép bạn thực bước nhỏ viết phần mềm.Đây thực tế mà người ta phát huy nhiều năm qua mang lại hiệu nhiều so với cố gắng viết mã bước lớn. Ví dụ, giả sử bạn thêm số mã nguồn cho chức mới, biên dịch, kiểm thử nó. Khả lớn kiểm thử bạn thất bại lỗi có mã nguồn mới. Sẽ dễ dàng nhiều việc tìm kiếm, sau sửa chữa lỗi bạn viết thêm hai dòng mã thay hai nghìn dòng. Nhiều người cho kỹ thuật Agile hoạt động ổn với dự án nhỏ, cần số người vài tháng, chúng không hoạt động dự án thực lớn hơn. Tuy nhiên, điều không hoàn toàn đúng. Người ta đưa NHÓM 8: TEST-DRIVEN DEVELOPMENT báo cáo làm việc với hệ thống Smalltalk sử dụng hoàn toàn phương pháp hướng kiểm thử (test-driven) hết năm với chi phí nhân công 40 man-year, kết gồm 250,000 dòng mã nguồn chức 250,000 dòng mã kiểm thử. Có 4000 mẫu kiểm thử chạy 20 phút, với mẫu kiểm thử đầy đủ cần chạy vài ngày. Điều chứng tỏ TDD hoạt động tốt với dự án có kích thước lớn. III. Chu trình phát triển Chu trình phát triển TDD 1. Add a test Trong phát triển dựa kiểm thử, tính bắt đầu cách viết kiểm thử (a test) . Kiểm thử chắn phải thất bại viết trước tính thực (nếu không thất bại, đề xuất tính " " NHÓM 8: TEST-DRIVEN DEVELOPMENT tồn kiểm thử khiếm khuyết). Để viết kiểm thử (a test), nhà phát triển phải hiểu rõ đặc tả yêu cầu tính này. Nhà phát triển thực điều thông qua mô hình Use cases câu chuyện người sử dụng bao gồm yêu cầu điều kiện ngoại lệ, viết test framework kiểm thử phù hợp với môi trường phần mềm. Điều dẫn đến sửa đổi test . Đây tính khác biệt phát triển dựa kiểm thử so với kiểm thử đơn vị sau mã viết: làm cho nhà phát triển tập trung vào yêu cầu trước viết mã. 2. Run all tests and see if the new one fails Điều xác nhận kiểm thử (test) làm việc cách xác test không pass nhầm mà không cần code nào. Bước kiểm thử test, trường hợp tiêu cực: bác bỏ khả kiểm thử luôn pass, vô giá trị. Các test fail lý kỳ vọng. Điều làm tăng tự tin (mặc dù không đảm bảo) mà kiểm thử đúng, pass trường hợp dự định. 3. Write some code Bước viết số mã tạo kiểm thử để pass. Mã viết giai đoạn không hoàn hảo. Điều chấp nhận bước sau cải thiện nó. Tại thời điểm này, mục đích mã viết phải vượt qua test, thêm chức (và chưa kiểm tra) nên dự đoán "cho phép" lúc nào. 4. Run tests Nếu tất test cases pass, lập trình viên tự tin code đáp ứng tất yêu cầu. Đây thời điểm tốt để bắt đầu bước cuối chu kỳ phát triển. NHÓM 8: TEST-DRIVEN DEVELOPMENT 5. Refactor code Tái cấu trúc trình làm thay đổi có, code mà không cần thay đổi hành vi bên nó. Nói cách khác, thay đổi mà phải nó, làm. Mục đích để cải thiện cấu trúc nội bộ. Các tình cần phải cấu trúc lại là: - Khi có trùng lặp. Khi thấy code và/hoặc mục đích không rõ ràng. Khi cảm thấy code có vấn đề (theo cảm tính) 6. Repeat Bắt đầu với kiểm thử (a test) mới, chu kỳ sau lặp lặp lại để hoàn thiện chức năng. Kích thước bước cần luôn nhỏ, với 1-10 sửa đổi lần chạy kiểm thử. Nếu mã không nhanh chóng đáp ứng kiểm thử mới, kiểm thử khác fail không ngờ tới, lập trình viên nên lùi lại trở lại ưu tiên cho gỡ lỗi nhiều hơn. IV. Thuận lợi sử dụng TDD 1. Chất lượng tốt với TDD a. Chất lượng nhiều khía cạnh Bằng chứng phận đảm bảo chất lượng giới doanh nghiệp ngày , có xu hướng gán chất lượng với số lỗi tìm sau sử dụng phần mềm. Một số khác lại coi việc chất lượng thứ khác mức độ mà phần mềm đáp ứng nhu cầu mong đợi từ người dùng. Một só xem xét không chất lượng nhìn từ bên mà đặc tính bên phần mềm (bên : chi phí phát triển bảo trì). TDD góp phần cải thiện chất lượng tất khía cạnh với thiết kế hướng dẫn chất lượng theo định hướng chất nó. Rất nhiều lí cho lỗi sơ suất trình tạo sản phẩm, không test xác minh lại trường hợp đặc biệt mà theo code hoạt động đúng(có thể không chạy test chạy test cách cẩu thả). TDD giải vấn đề cách đảm bảo có thực tế mã code hệ thống không yêu cầu thực test. TDD hiệu đảm bảo điều bạn viết NHÓM 8: TEST-DRIVEN DEVELOPMENT test cho, chất lượng có nhiều hàm chức làm thành công , qua testcase. Một phần quan trọng nhiệm vụ vấn để kĩ test khả lấy testcase cho trường hợp bình thường , trường hợp biên, người sử dụng dự đoán lỗi,… Các TDD hỗ trợ phần cách cho phép tập trung vào giao diện cho module, class, bạn có. Bởi cài đặt nào, định vị tốt việc nghĩ khuôn khổ tập trung làm để code nên xử lívà làm để nhà phát triển khách hàng , muốn sử dụng nó. Điều quan trọng suốt trình phát triển vấn đề phát sớm chỉnh sửa chúng tìm thấy. Thông thường vấn đề lớn xảy có hiểu lầm, hiểu sai yêu cầu khách hàng người lập trình.những vấn đề tránh có cách để xác định yêu cầu rõ trước bắt đầu phát triển. Nhập test. Các test xác định yêu cầu cách mà không yêu cầu người giải thích thành công hay thất bại . Nếu có đủ số lượng test chúng tạo trước phát triển . Chỉ đơn giản chạy test định thành công hay thất bại giúp giải vấn đề cũ phát triển phần mềm. “Are We Done?” Câu trả lời giải thích dài dòng, mà code có qua tất test hay không. Sau qua test, nghĩa hoàn thành. Giải pháp cho vấn đề đủ, nhiêù thế. Các test viết trình phát triển , chạy tăng cường đảm bảo chất lượng phần mềm(QA) với test. Vì code viết với việc test động lực , sở chính, kết code dễ dàng để test. Có sở test có code dễ để test nên cho cho phép chuyển từ việc phản ứng thụ động sang chủ động thân test hữu dụng không phát triển ban đầu phần mềm , chúng trì với việc viết code, chúng sử dụng để trì phần mềm. Ví dụ, sản phẩn phát trình viết code, bước nên viết test để xác định rõ ràng vấn đề sau đó, bạn có test fail, có vấn đề. Sau đó, test xác định kịch mà xác định suốt trình phát triển trước đó. Nếu bạn làm quán điều này. Các test phát triển thành chương trình sử dụng đời sống thực, làm tăng giá trị chúng theo cấp số nhân. Khi thêm tính bạn chạy test để chắn mã code không phá vỡ test có . Nếu bao quát test đủ, chạy test nhận kết thành công giảm lo ngại bạn . Sự phá vỡ chức vị bạn thận trọng, làm bạn chậm chạp hơn. Viẹc dùng test cách để lấy lại cân hướng để bạn phát triển chương trình. b. Thời gian cho fix lỗi NHÓM 8: TEST-DRIVEN DEVELOPMENT TDD giúp tăng tốc độ cách giảm thời gian cần đẻ sửa chữa lỗi . Một cảm giác phổ biến sửa chữa lỗi sau sản phẩm sử dụng hai tháng nhiều thời gian tiền bạc nhiều so với sửa chữa với gnày giới thiệu. Bất điều làm để giảm thiểu số lõi giới thiệu lần đầu tiên, để giúp tìm thấy lỗi làm, ràng buộc phải trải qua. Tiến hành tesst bước nhỏ để đảm bảo bạn chạm vào việc fix lỗi. TDD giúp xây dựng code với chất lượng kĩ thuật code , mong đợi code dễ dàng để hiểu để làm việc với nó. Ngay code tốt văn 2. Nhu cầu việc trao đổi để xác định chức Giúp định hình ý tưởng thiết kế kiểm nghiệm mã chương trình, thực theo TDD làm sáng tỏ thêm yêu cầu toán, giải tỏa bế tắc tim giải pháp phát sớm vấn đề thiết kế tránh công việc phải làm lại. Chúng ta xác định toán 1. Có thể làm tài liệu cho nhà phát triển Các nhà phát triển thường thích đọc code ví dụ gặm nhấm tài liệu giải thích vấn đề kĩ thuật ngôn ngữ phi kỹ thuật. TDD làm xác công việc đó. Việc thêm vài comment trước test cần, bạn có tài liệu hướng dẫn cho nhà phát triển khác. Tất nhiên cần phân biệt tài liệu cho nhà phát triển cho người sử dụng. Tài liệu cho nhà phát triển cần có hướng dẫn tổng quan, phương pháp luận , quy ước…. 2. Các lập trình viên làm chủ Các lập trình viên làm thứ code mà không sợ ảnh hưởng đến hệ thống miễn code đảm bảo pass qua test. Không dám đảm bảo điều với hệ thống có nhiều nguy cơ, lập trình viên không cần quan tâm đến điều đó. Với test hoàn thành fail chứng tỏ bạn phá vỡ pass bạn không cần phải làm cả. V. Hướng phát triển, áp dụng TDD cho công nghệ phát triển 1. Test_driving với thành phần web a. Test-driving với Java Servlets Có đối số HttpServletRequest đại diện yêu cầu phương HTTP đóng gói thông số cần thiết. Đối tượng yêu cầu hoạt động phương tiện truyền liệu từ thành phần yêu cầu xử lý liệu.Đối số thứ đối tượng HttpServletResponse cổng để tạo phản ứng cho phía client. Làm để test này? Chúng ta tạo request response giả mạo. 10 NHÓM 8: TEST-DRIVEN DEVELOPMENT Nếu muốn test cho Servlet trước, cần phải xác minh thực tạo response dự kiến. Chúng ta phải cung cấp trường hợp mà HttpServletRequest HttpServletResponse gọi với cặp test có sẵn bên thứ ba. Sau nữa, test trước thực Servlet bình thường. Với yêu cầu phức tạp hơn, ví dụ xử lý chuyển hướng đăng nhập . Làm để Servlet xử lý đăng nhập ? đăng nhập thất bại sai mật thông qua chuyển tiếp yêu cầu tới trang báo lỗi . Chúng ta muốn mô request, kiểm tra xem request chuyển hướng đến trang lỗi chưa.Việc thực giả HttpServletResponse cho phép làm điều . public class TestLoginServlet { @Test public void wrongPasswordShouldRedirectToErrorPage() throws Exception { HttpServlet servlet = new LoginServlet(); MockHttpServletRequest request = create fake request object 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 Ngoài làm việc parameter session thời điểm public void validLoginForwardsToFrontPageAndStoresUsername() throws Exception { HttpServlet servlet = new LoginServlet(); MockHttpServletRequest request = new MockHttpServletRequest("GET", "/login"); request.addParameter("j_username", "validuser"); request.addParameter("j_password", "correctpassword"); MockHttpServletResponse response = new MockHttpServletResponse(); servlet.service(request, response); 11 NHÓM 8: TEST-DRIVEN DEVELOPMENT assertEquals("/frontpage", response.getRedirectedUrl()); assertEquals("validuser", request.getSession().getAttribute("username")); phát triển hướng tới thiết kế tốt Từ khóa để giữ Java Servlets không lỗi kiểm chứng phân chia chinh phục. Lập trình ý tưởng, nhầm có test pass bước nhỏ . b. Test-driving với Spring controllers Framework Spring ứng với phần C mô hình MVC , chúng tương tự Servlet trừu tượng hơn. Đối với Spring Controller không chịu trách nhiệm response cho request. Thay vào đó, chúng mà framework trả lại đối tượng ModelAndView. public class SampleController implements Controller { protected ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { return new ModelAndView("viewname"); } } Các sampleController ánh xạ để xử lý URL cụ thể. Đối tượng request đến cổng để lấy tất dữliệu cần để làm điều SampleController cần để làm, đối tượng ModelAndView trả lại nói với Spring MVC nhằm trả lại response Chúng ta bắt đầu viết test thứ với ví dụ đăng nhập tương tự với Spring MVC public class TestLoginController { @Test public void wrongPasswordShouldRedirectToErrorPage() throws Exception { MockHttpServletRequest request = new MockHttpServletRequest(); request.addParameter("j_username", "nosuchusername"); request.addParameter("j_password", "nosuchpassword"); MockHttpServletResponse response = new MockHttpServletResponse(); Controller c = new LoginController(); ModelAndView v = c.handleRequest(request, response); populate mock obj invock 12 NHÓM 8: TEST-DRIVEN DEVELOPMENT assertEquals("wrongpassword", v.getViewName()); wrongpass } } Chúng ta tạo B kiểm thử kép với giao diện request response, sau C gọi phương thức xử lý request với kiểm thử kép cuối D thực assertioin để xác minh hành vi mong đợi. Sự khác biệt với Servlet khái niệm ModelAndView, mang tất liệu để biểu diễn . 2. Test-driving với truy cập liệu Sự khác biệt truy cập sở liệu hành vi thường kéo dài nhiều lớp kiến trúc hệ thống. Nó có xu hướng sử dụng API bên thứ ba . Để test mà không cần công cụ bên thứ ba cần tách rời vấn đề này. Chúng ta bắt đầu với xác định ranh giới truy cập liệu, sau nghiên cứu mẫu thiết kế để test. Biên Làm việc tầng Application logic , dễ dàng để sơ khai persistence logic. Chúng ta xác minh business logic, testing gọi phương thức thích hợp giao diện tầng persistence logic phù hợp với parameters. Phát triển phần mềm thường theo kiểu truyền thống dựa phương pháp thủ công, kiểm tra trực quan cho truy cập liệu. Việc kiểm tra trực quan chậm dễ bị lỗi. Chúng ta cần sử dụng dịch vụ kiên trì từ test driven. Cho đến bỏ qua liệu yếu tố test cách giả mạo nó. Chúng ta có lợi tương đối bất lời cho việc áp dụng TDD với việc hội nhập chiến lược khác cho quản lý liệu test chúng ta. 3. Test-driving the unpredictable Chúng ta đến cụ thể hàm chức java a. Test-driving với chức theo thời gian 13 NHÓM 8: TEST-DRIVEN DEVELOPMENT Nhiều developer lần đối mặt với vấn đề viết test cho đoạn code có đầu hành vi phụ thuộc vào thời gian tại. Vấn đề với thời gian kiểm soát nó. Các vấn đề liên quan : trừu tượng hóa thời gian hệ thống, test vói log output với thời gian hệ thống giả. b. Test-driving với đa luồng Chúng ta xét luồng chương trình đơn giản với quy định rõ ràng xác định bước thực chương trình logic. Đồng thời, mã đa luồng khác nhau. Việc thực xác định nữa, với nhiều threads tương tác với cạnh tranh để truy cập vào đối tượng. Tương tự vậy, có khác biệt mã liên tục đồng thời cách test hành vi mong muốn đoạn mã. Khi test_driving code hệ thống, không quan tâm văn test cho hành vi liên tục mà hành vi đồng thời sau không gian lỗi lớn hơn. Chúng ta xét kỹ hai khía cạnh Mở rộng không gian lỗi Trong concurrent programming, có nhiều cách sai, kịch có nhiều khó khăn để mô phỏng. Nói cách khác, concurrent programming có không gian lỗi lớn nhiều so với đối tác liên tục chúng. Hơn test code vo tình ảnh hưởng đến đồng thời mã test, gây tượng gọi Heisenbugs lỗi mà biến thêm test debug . Sự khác biệt số lượng lỗi tiềm đáng kể, đủ cho chúng không thực tế. Chúng ta có phương sách để mô vài lựa chọn rõ ràng Mặc dù phân tích thủ công loại bỏ rõ ràng hầu hết lỗi, nên tăng tự tin hệ thống hành vi Concurrent, cách sử dụng lặp lặp lại , chạy test dài để xác định lỗi xảy cách ngẫu nhiên. Nhiều hành vi concurrent Có nhiều loại hành vi mà nhắm tới mục tiêu kiểm thử đơn vị : Good stuff, bad stuff. 4. Test-driving với Swing Những cần quan tâm kiểm thử mộtgiao diện đồ họa ngừoi dùng? Mặc dù câu trả lời đơn giản hướng chung cho nhà phát triển Swing, xác định số loại khác thuộc tính khác code Swing đưa số câu trả lời cách tập trung vào loại thời điểm: Internal plumbing utilities, rendering and layout, interaction 14 NHÓM 8: TEST-DRIVEN DEVELOPMENT Internal plumbing and utilities Mặc dù giao diện người dùng cách trình bày bố trí hình ảnh, điều nghĩa cách phần code thực tế không giống với viết phát triển hệ thống. Redering and layout Chúng ta muuốn đặt layout để xác nhận phần việc kiểm tra mắt . Đôi cần test cho việc bố trí thô cần bố trí. Đó Tôi viết test” Button A nên button B bảng C đưa ra” or “Button A B có độ rộng tương tự đưa hình” Interaction Các thành phần giao diện vô ích tương tác với ứng dụng. Loại tương tác test cách tầm thường giống mã tiện ích mà chúng phụ thuộc vào Swing API. Nó không đòi hỏi thông thái, kiểm tra tương tương tác mong muốn dễ dàng miễn biết Swing API. Ví dụ cần phải làm thành phần Swing nhận input ngừoi dùng đăng nhập vàođể mô mong đọi test đơn vịcủa VI. Thách thức 1. Thời gian đầu tư lớn Đối với trường hợp đơn giản bạn khoảng 20% thời gian cài đặt, với dự án phức tạp lớn nhiều 2. Phức tạp Trong toán phức tạp , khó để tính toán testcase, trường hợp test tự động song song với thiết kế dùng test đơn vị đơn giản 3. Gắn liền với thiết kế Một số trường hợp phần thiết kế không rõ ràng từ đầu , thống kết thúc nên đòi hỏi việc viết test lâu khó khăn. 4. Cần phải tinh chỉnh liên tục Với cấu trúc liệu kiểm thử hộp đen việc kiểm thử đơn vị hoàn hảo. Nhưng với thuật toán có hướng thay đổi, tinh chỉnh điều chỉnh tốt . Điều cần đầu tư thời gian lớn mà việc bồi thường kinh phí không hợp lý, sử dụng cần cân nhắc đến hệ thống triển khai 15 NHÓM 8: TEST-DRIVEN DEVELOPMENT 5. Liên quan chặt chẽ đến ”Agile” Không đặt tầm quan trọng vào tài liệu hệ thống, tất nằm nhà phát triển , nhà phát triển không tiếp tục lâu dài quên có giá trị trả mà giá trị khác tất mơ hồ. TDD tốt mà việc ghi chép tài liệu cho test phải rõ ràng. VII. Đặc điểm Unit Test (Kiểm thử đơn vị) Unit Test (UT) kỹ thuật quan trọng góp phần nâng cao chất lượng phần mềm (PM), có nhiều quan điểm trái ngược việc đưa UT vào quy trình phát triển PM. Sau đặc điểm UT với mô hình phát triển phần mềm đại TDD 1. Định nghĩa: UT kỹ thuật kiểm nghiệm hoạt động chi tiết mã (code) với quy trình tách biệt với quy trình phát triển PM, giúp phát sai sót kịp thời. UT giúp phát vấn đề tiềm ẩn lỗi thời gian thực trước chuyên viên kiểm định chất lượng (QA - Quality Assurance) tìm ra, chí sửa lỗi từ ý tưởng thiết kế. 2. Cấu trúc UT: UT đoạn mã có cấu trúc giống đối tượng xây dựng để kiểm tra phận hệ thống. Mỗi UT gửi thông điệp kiểm tra câu trả lời nhận hay không, bao gồm: • Các kết trả mong muốn • Các lỗi ngoại lệ mong muốn Các đoạn mã UT hoạt động liên tục định kỳ để thăm dò phát lỗi kỹ thuật suốt trình phát triển, UT gọi kỹ thuật kiểm nghiệm tự động. 3. Đặc điểm UT • Đóng vai trò người sử dụng hệ thống 16 NHÓM 8: TEST-DRIVEN DEVELOPMENT • Chỉ có giá trị chúng phát vấn đề tiềm ẩn lỗi kỹ thuật. 4. Vòng đời UT • Fail (trạng thái lỗi) • Ignore (tạm ngừng thực hiện) • Pass (trạng thái làm việc) Toàn UT vận hành hệ thống tách biệt. Có nhiều PM hỗ trợ thực thi UT với giao diện trực quan. Thông thường, trạng thái UT biểu màu khác nhau: màu xanh (pass), màu vàng (ignore) màu đỏ (fail). UT thực đem lại hiệu khi: • Được vận hành lặp lại nhiều lần • Tự động hoàn toàn • Độc lập với UT khác. 5. Thiết kế UT Mỗi UT tiết kế theo trình tự sau: • Thiết lập điều kiện cần thiết: khởi tạo đối tượng, xác định tài nguyên cần thiết, xây dựng liệu giả . • Triệu gọi phương thức cần kiểm tra. • Kiểm tra hoạt động đắn phương thức. • Dọn dẹp tài nguyên sau kết thúc kiểm tra. 6. Ứng dụng UT • Kiểm tra đơn vị nhỏ thuộc tính, kiện, thủ tục hàm. • Kiểm tra trạng thái ràng buộc đối tượng mức sâu mà thông thường truy cập được. • Kiểm tra quy trình (process) mở rộng khung làm việc(workflow - tập hợp nhiều quy trình). 7. Lợi ích UT 17 NHÓM 8: TEST-DRIVEN DEVELOPMENT • Thời gian đầu, người ta thường dự phải viết UT thay tập trung vào viết mã cho chức nghiệp vụ. Công việc viết UT ngốn nhiều thời gian, nhiên UT đem lại lợi ích to lớn như: • Tạo môi trường lý tưởng để kiểm tra đoạn mã nào, có khả thăm dò phát lỗi xác, trì ổn định toàn PM giúp tiết kiệm thời gian so với công việc gỡ rối truyền thống. • Phát thuật toán thực thi không hiệu quả, thủ tục chạy vượt giới hạn thời gian. • Phát vấn đề thiết kế, xử lý hệ thống, chí mô hình thiết kế. • Phát lỗi nghiêm trọng xảy tình hẹp. • Tạo hàng rào an toàn cho khối mã: Bất kỳ thay đổi tác động đến hàng rào thông báo nguy hiểm tiềm tàng. UT tạo thành hàng rào an toàn cho mã ứng dụng • UT môi trường lý tưởng để tiếp cận thư viện API bên cách tốt nhất. Sẽ nguy hiểm ứng dụng thư viện mà không kiểm tra kỹ lưỡng công dụng thủ tục thư viện. Dành thời gian viết UT kiểm tra thủ tục phương pháp tốt để khẳng định hiểu đắn cách sử dụng thư viện đó. Ngoài ra, UT sử dụng để phát khác biệt phiên phiên cũ thư viện. Trong môi trường làm việc cạnh tranh, UT có tác dụng lớn đến suất làm 18 NHÓM 8: TEST-DRIVEN DEVELOPMENT việc: • Giải phóng chuyên viên QA khỏi công việc kiểm tra phức tạp. • Tăng tự tin hoàn thành công việc. Chúng ta thường có cảm giác không chắn đoạn mã liệu lỗi có quay lại không, hoạt động module hành có bị tác động không, liệu công việc hiệu chỉnh mã có gây hư hỏng . • Là công cụ đánh giá lực bạn. Số lượng tình kiểm tra (test case) chuyển trạng thái "pass" thể tốc độ làm việc, suất bạn. 8. Chiến lược viết mã hiệu với UT • Phân tích tình xảy mã. Đừng bỏ qua tình tồi tệ xảy ra, thí dụ liệu nhập làm kết nối sở liệu thất bại, ứng dụng bị treo phép toán chia cho không, thủ tục đưa lỗi ngoại lệ sai phá hỏng ứng dụng cách bí ẩn . • Mọi UT phải bắt đầu với trạng thái "fail" chuyển trạng thái "pass" sau số thay đổi hợp lý mã chính. • Mỗi viết đoạn mã quan trọng, viết UT tương ứng bạn nghĩ thêm tình nữa. • Nhập số lượng đủ lớn giá trị đầu vào để phát điểm yếu mã theo nguyên tắc: - Nếu nhập giá trị đầu vào hợp lệ kết trả phải hợp lệ - Nếu nhập giá trị đầu vào không hợp lệ kết trả phải không hợp lệ • Sớm nhận biết đoạn mã không ổn định có nguy gây lỗi cao, viết UT tương ứng để khống chế. • Ứng với đối tượng nghiệp vụ (business object) đối tượng truy cập liệu (data access object), nên tạo lớp kiểm tra riêng lỗi nghiêm trọng phát sinh từ đối tượng này. • Để ngăn chặn lỗi phát sinh trở lại thực thi tự động tất UT có thay đổi quan trọng, làm công việc ngày. Các UT lỗi cho biết thay đổi nguyên nhân gây lỗi. • Để tăng hiệu giảm rủi ro viết UT, cần sử dụng nhiều phương thức kiểm tra khác nhau. Hãy viết đơn giản tốt. 19 NHÓM 8: TEST-DRIVEN DEVELOPMENT • Cuối cùng, viết UT đòi hỏi nỗ lực, kinh nghiệm sáng tạo viết PM. VIII. KHUNG KIỂM THỬ PYUNIT 1. Khái niệm: - PyUnit phiên ngôn ngữ Python JUnit (trên ngôn ngữ Java) , viết Kent Beck Erich Gramma. PyUnit thư viện hỗ trợ việc kiểm tra tự động hóa, chia sẻ thiết lập ngừng việc thay đổi mã nguồn để thử nghiệm, tổng hợp test , chạy chúng cách độc lập sau trả báo cáo. Những module có sẵn unittest cung cấp lớp hỗ trợ cho tập hợp kiểm tra tương ứng 2. Những API quan trọng unittest - Để đat điều unittest hỗ trợ khái niệm sau: o Test fixture : Thử nghiệm đại diện cho việc chuẩn bị cần thiết để thực hay nhiều kiểm tra hành động dọn dẹp liên kết cần thiết o Test Case : Là đơn vị nhỏ thử nghiệm, kiểm tra phản ứng cụ thể cho tập hợp yếu tố đầu vào. TestCase sử dụng để tạo trường hợp thử nghiệm mới. Tuy nhiên bạn sử dụng cách bạn thay sử dụng phân lớp từ Unittest o Test Suite : tập hợp TestCase TestSuite. Nó sử dụng để kiểm tra tổng hợp, cần có kiểm tra để bắt đầu TestSuite o Test Runner : chạy thử nghiệm thành phần trả kết kiểm tra cho người sử dụng . Nó sử dụng giao diện đồ họa, giao diện văn giá trị đặc biệt để kết kiểm tra 3. Cấu trúc đơn giản testCase - - Bắt buộc cần khai báo thư viện unittest để chương trình hiểu sử dụng thư viện Cần lấy hàm cần test làm thư viện để chương trình hiểu thực thi 20 NHÓM 8: TEST-DRIVEN DEVELOPMENT - - Các test gọi đến class, test testCase gọi chạy độc lập với nhau, sau thống kê xem có test vượt qua test lỗi Câu lệnh if __name__ == “__main__” sử dụng để gọi tới chương trình chính, tập tin gọi nơi khác name thiết lập theo tên module IX. DEMO CHƯƠNG TRÌNH PHÁT TRIỂN THEO HƯỚNG TDD SỬ DỤNG PYUNIT BÀI TOÁN: Với đầu vào giá trị cạnh tam giác. Yêu cầu chương trình cần kiểm tra đầu vào có thỏa mãn điều kiện chúng tạo thành tam giác hay không, tam giác loại tam giác nào? HƯỚNG GIẢI QUYẾT: Từ yêu cầu toán nêu trên, ta tập trung tạo trường hợp toán , đưa vào TestCase PyUnit, sau thực thi unittest. Quay trở lại chỉnh sửa mã nguồn hợp lý để có kết mong đợi. Sau hoàn thành TestCase ta tạm tin tưởng thời điểm chương trình đáp ứng TestCase cho, giải tình tương tự Video demo tại: http://www.youtube.com/watch?v=NLe0558de54 21 NHÓM 8: TEST-DRIVEN DEVELOPMENT X. TÀI LIỆU THAM KHẢO Beck, Kent Test-Driven Development: By Example Addison-Wesley, 2003. S. Amber. Introduction to Test Driven Development (TDD), www.agiledata.org http://www.testdriven.com Learn Python The Hard Way Release Zed a Shaw Unit Testing Framework: http://docs.python.org/2/library/unittest.html 22 [...]... NHÓM 8: TEST- DRIVEN DEVELOPMENT X TÀI LIỆU THAM KHẢO Beck, Kent Test- Driven Development: By Example Addison-Wesley, 2003 S Amber Introduction to Test Driven Development (TDD), www.agiledata.org http://www.testdriven.com Learn Python The Hard Way Release Zed a Shaw Unit Testing Framework: http://docs.python.org/2/library/unittest.html 22 ... các thiết lập và ngừng việc thay đổi mã nguồn để thử nghiệm, tổng hợp các test , chạy chúng một cách độc lập sau đó trả về các báo cáo Những module có sẵn của unittest cung cấp các lớp hỗ trợ cho một tập hợp các bài kiểm tra tương ứng 2 Những API quan trọng của unittest - Để đat được những điều trên unittest hỗ trợ những khái niệm sau: o Test fixture : Thử nghiệm đại diện cho việc chuẩn bị cần thiết... hiểu và sử dụng thư viện này Cần lấy hàm cần test làm thư viện để chương trình hiểu và thực thi 20 NHÓM 8: TEST- DRIVEN DEVELOPMENT - - Các bộ test sẽ được gọi đến trong class, khi test mỗi testCase sẽ được gọi và chạy độc lập với nhau, sau đó thống kê xem có bao nhiêu test đã vượt qua và bao nhiêu test vẫn còn lỗi Câu lệnh if name == “ main ” được sử dụng để gọi tới chương trình chính, nếu tập tin được... trong java a Test- driving với chức năng theo thời gian 13 NHÓM 8: TEST- DRIVEN DEVELOPMENT Nhiều developer đã ít nhất một lần đối mặt với vấn đề viết một test cho một đoạn code có đầu ra hoặc hành vi phụ thuộc vào thời gian hiện tại Vấn đề với thời gian là chúng ta không thể kiểm soát nó Các vấn đề liên quan : trừu tượng hóa thời gian hệ thống, test vói log output với thời gian hệ thống giả b Test- driving... có thể bắt đầu một TestSuite o Test Runner : là chạy thử nghiệm một thành phần và trả về kết quả kiểm tra cho người sử dụng Nó có thể sử dụng giao diện đồ họa, giao diện văn bản hoặc giá trị đặc biệt để chỉ ra kết quả của các bài kiểm tra 3 Cấu trúc đơn giản của một testCase - - Bắt buộc cần khai báo thư viện unittest để chương trình hiểu và sử dụng thư viện này Cần lấy hàm cần test làm thư viện để... kiểm tra trực quan cho các truy cập dữ liệu Việc kiểm tra trực quan là chậm và dễ bị lỗi Chúng ta cần sử dụng dịch vụ kiên trì từ test driven Cho đến nay chúng ta bỏ qua dữ liệu là một yếu tố trong test của chúng ta bằng cách giả mạo nó Chúng ta có những lợi thế tương đối và bất lời cho việc áp dụng TDD với việc hội nhập và các chiến lược khác nhau cho quản lý dữ liệu test của chúng ta 3 Test- driving... toán , đưa nó vào TestCase của PyUnit, sau đó thực thi unittest Quay trở lại chỉnh sửa mã nguồn hợp lý để có kết quả như mong đợi Sau khi đã hoàn thành các TestCase ta có thể tạm tin tưởng tại thời điểm hiện tại chương trình có thể đáp ứng được các TestCase đã cho, giải quyết được những tình huống tương tự Video demo tại: http://www.youtube.com/watch?v=NLe0558de54 21 NHÓM 8: TEST- DRIVEN DEVELOPMENT X TÀI... dẹp liên kết cần thiết o Test Case : Là đơn vị nhỏ nhất của thử nghiệm, nó kiểm tra một phản ứng cụ thể cho một tập hợp các yếu tố đầu vào TestCase có thể được sử dụng để tạo ra các trường hợp thử nghiệm mới Tuy nhiên bạn có thể sử dụng cách của bạn thay vì sử dụng phân lớp này từ Unittest o Test Suite : là một tập hợp của các TestCase và TestSuite Nó được sử dụng để kiểm tra tổng hợp, vì thế cần có...NHÓM 8: TEST- DRIVEN DEVELOPMENT Nếu chúng ta muốn test cho Servlet trước, cần phải xác minh rằng nó thực sự tạo ra 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 Sau đó nữa, các test trước được thực hiện một Servlet bình thường Với yêu cầu... ”Agile” Không đặt tầm quan trọng vào tài liệu của hệ thống, tất cả nằm trong nhà phát triển , nếu nhà phát triển không tiếp tục lâu dài hoặc quên đi tại sao chỉ có một giá trị trả về mà không phải là các giá trị khác thì tất cả đều rất mơ hồ TDD tốt khi mà việc ghi chép tài liệu cho các test phải rõ ràng VII Đặc điểm của Unit Test (Kiểm thử đơn vị) Unit Test (UT) là một kỹ thuật quan trọng góp phần nâng . Nội, 15/10/2013 1 NHÓM 8: TEST- DRIVEN DEVELOPMENT MỤC LỤC 2 NHÓM 8: TEST- DRIVEN DEVELOPMENT NỘI DUNG CHÍNH A. LÝ THUYẾT I. Định nghĩa Test- driven Development Test- driven Development (TDD) là một. NHÓM 8: TEST- DRIVEN DEVELOPMENT BÁO CÁO BÀI TẬP LỚN NGÀNH : CÔNG NGHỆ THÔNG TIN ĐỀ TÀI: TEST DRIVEN DEVELOPMENT DANH SÁCH NHÓM 8: 1.PHẠM ANH ĐẠT (Nhóm. này từ Unittest o Test Suite : là một tập hợp của các TestCase và TestSuite. Nó được sử dụng để kiểm tra tổng hợp, vì thế cần có các bộ kiểm tra để có thể bắt đầu một TestSuite o Test Runner