Vậy TDD – Test Driven Development là gì? Nôm na có thể hiểu đây là phương pháp phát triển phần mềm theo hướng viết test trước khi viết code, ngược lại với cách truyền thống xưa nay chúng ta vẫn làm là viết code rồi mới thực hiện test.
Buổi meetup số 3 này có 30 bạn đăng kí tham dự, số lượng thực tế đến buổi meetup là 10 bạn đến từ các công ty khác nhau trong ngành như: R&D của Vietcombank, VNPT, Nova Ads…
Dưới đây là một số hình ảnh về buổi meetup:
Diễn giả chia sẻ lần này như đã giới thiệu là bạn Lê Anh đến từ Công ty viễn thông toàn cầu GTel, blog: http://apollo13.vn/
T2.png” alt=”*”>
T4.png” alt=”*”>
T6.jpg” alt=”*”>
Slide của buổi hội thảo các bạn có thể xem trong view bên dưới Ads –một nhà cung cấp giải pháp quảng cáo trực tuyến lớn tại Việt Nam.
Các thông tin chi tiết sẽ được thông báo dần tại địa chỉ meetup http://www.meetup.com/Ha-Noi-NET-Meetup/, Facebook hoặc tại blog này vì vậy các bạn vui lòng subscribe blog để nhận được thông tin mới nhất.
Ngoài ra chúng tôi rất mong các lập trình viên .NET đăng kí làm presenter chia sẻ các kiến thức cũng như kinh nghiệm của mình về bất kì khía cạnh nào trong .NET. Nếu các bạn muốn chia sẻ hãy nhanh tay đăng kí với tôi qua email .
Top Posts & Pages Archives Categories Tags .NET ASP.NET MVC 6 Authentication Service BDD Bootstrap Clean Clean Code Conferences Continuous Delivery Continuous Integration Culture Info Fiddler Interview j Query Kỹ thuật blog Localize Lập trình hướng đối tượng Membership Microsoft Technology Day Neo4j nosql OOP Refactoring Signal R Soft Skill SQL Optimization SQL Server TDD Team Foundation Server 2010 Team Foundation Server 2013 Team Foundation Server 2015 Test Driven Development Testing Tips&Trick UI Prototype Visual Studio 2010 Visual Studio 2013 Visual Studio 2015 WCF WCF REST Web API Web Service Windows Phone 7 Windows Phone 8.1 Winform Follow me on Twitter & Facebook My Tweets
Press · Log in
Send to Email Address Your Name Your Email Address
Cancel Post was not sent – check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. %d bloggers like this:
Là một developer trong công ty Nhật đang áp dụng tìm hiểu mô hình TDD nên mình muốn chia sẽ hiểu biết của mình về Test-Driven Development (TDD) và Behavior-Driven Development (BDD) – mô hình phát triển phần mềm hướng kiểm thử (test oriented) theo tinh thần Agile đang được áp dụng rộng rãi.
1. TDD là gì?
Chính xác với nghĩa đen của nó: “Test-Driven Development” có thể được tạm hiểu là mô hình phát triển với trọng tâm hướng về việc kiểm thử. TDD được xây dựng theo hai tiêu chí: Test-First (Kiểm thử trước) và Refactoring (Điều chỉnh mã nguồn) <1>. Trong đó, khi một yêu cầu phần mềm (requirement) được đặt ra:
Người developer soạn thảo kịch bản kiểm thử (test case) cho yêu cầu đó trước tiên và chạy thử kịch bản đó lần đầu tiên. Hiển nhiên, việc chạy thử sẽ đưa ra 1 kết quả thất bại vì hiện tại chức năng đó chưa được xây dựng (và thông qua kết quả đó, ta cũng kiểm tra được là kịch bản kiểm thử đó được viết đúng).Theo đó, dựa vào mong muốn (expectation) của kịch bản kia, người developer sẽ xây dựng một lượng mã nguồn (source code) vừa đủ để lần chạy thứ 2 của kịch bản đó thành công.Nếu trong lần chạy thứ 2 vẫn đưa ra 1 kết quả thất bại, điều đó có nghĩa là thiết kế chưa ổn và người developer lại chỉnh sửa mã nguồn và chạy lại kịch bản đến khi thành công.Khi kịch bản kiểm thử được chạy thành công, người developer tiến hành chuẩn hóa đoạn mã nguồn (base-line code) và tiếp tục hồi quy với kịch bản kiểm thử tiếp theo. Việc chuẩn hóa bao gồm thêm các comment, loại bỏ các dư thừa, tối ưu các biến…
Mô hình BDD – TDD trong Agile mô phỏng bởi Paul Littlebury
Từ mô hình trên ta dễ dàng nhìn nhận được sự ưu việt BDD mang lại đặc biệt là trong các dự án phần mềm lớn và phức tạp, khi cả hai khía cạnh phân hóa vai trò và chất lượng phải đi đôi. Ngoài ra, việc chạy kịch bản kiểm thử và xử lý sớm các vấn đề thiết kế ngay trong khâu xây dựng giúp giảm thiểu tối đa chi phí và công sức sữa chữa lỗi.
Trong khi khái niệm BDD mang tính lý thuyết, việc ứng dụng của nó lại đặt nặng sự thực nghiệm. Để phát huy lợi ích về thời gian trong việc xây dựng kịch bản kiểm thử, ngôn ngữ và cách truyền tải là 1 thử thách khi phải đáp ứng khả năng đọc hiểu từ cả 2 khía cạnh: tự nhiên và thiết kế. Bằng sự vay mượn từ ngôn ngữ viết User Story, ngôn ngữ Gherkin được phát triển để phục vụ nhu cầu đó với cấu trúc đơn giản, hướng đối tượng và tương đồng cho mọi kịch bản: Given – When – Then (mình sẽ trình bày rõ hơn về ngôn ngữ này ở các loạt bài khác).
