TEST DRIVEN DEVELOPMENT LÀ GÌ

1. Demo Driven Development (TDD) là gì?

TDD là cách phát triển phần mềm từ kiểm tra case, test case sẽ tiến hành viết trước để khẳng định những yêu mong cơ bản cần có. Nói biện pháp khác, demo case mang lại từng chức năng sẽ được sinh sản để kiểm tra trước khi code, nếu thử nghiệm case fail thì development sẽ kiểm tra và update code để pass được thử nghiệm case đã tạo thành trước kia .Mục đích thiết yếu của TDD là viết code rõ ràng, đơn giản dễ dàng và ít lỗi.

Bạn đang xem: Test driven development là gì

TDD bắt đầu bằng việc thiết kế và viết test cho đầy đủ chức năng nhỏ dại của ứng dụng. Theo phong cách tiếp cận TDD, đầu tiên là test sẽ tiến hành viết nhằm validate đoạn code đang làm chiếc gì, làm đúng hay chưa.

Ở tiến trình kiểm thử ứng dụng thông thường, bọn họ viết code rồi bắt đầu viết test. Test hoàn toàn có thể lỗi vì chưng test sau khi yêu mong đã được code xong. Để pass đoạn test này thì developer đề xuất refactor lại code.

*
Khái niệm dễ dàng và đơn giản của TDD là viết cùng chạy đúng những đoạn test bị lỗi trước lúc viết code mới. Điều này góp ta tránh khỏi việc lặp code vì chúng ta chỉ viết hồ hết đoạn code ngắn nhằm pass một yêu cầu nhỏ dại cần test.

TDD là 1 trong quy trình cải cách và phát triển và kiểm thử tự động trước khi thực sự bắt tay vào trở nên tân tiến ứng dụng (nôm na là trước lúc code). Bởi vậy mà TDD song khi có cách gọi khác với cái tên Test First Development

2. Ứng dụng TDD như vậy nào?

Sau đây là các bước để thực hành TDD:

Tạo testChạy test và check xem có lỗi xuất xắc khôngViết codeChạy demo và refactor code (đương nhiên là refactor để pass test)Lặp lại quá trình trên
*

Một vòng lặp của TDD có thể xác định như sau:

Viết testChạy testSửa code để chạy thử chạy đúngLặp lại 3 cách trên

Một số điều cần làm rõ về TDD:

TDD không phải tập trung về testing xuất xắc là về designTDD không tức là “viết những kịch phiên bản test rồi kiến tạo một khối hệ thống sao mang đến nó pass những kịch bản test này “TDD không có nghĩa là test nhiều hơn4. TDD với Testing truyền thống

Cách tiếp cận hình trạng TDD là 1 kỹ thuật sệt biệt. Nó đảm bảo an toàn rằng mã nguồn của người tiêu dùng luôn được kiểm soát kỹ lưỡng ở tầm mức độ chứng thực (confirm input/output)

Với kiểm test truyền thống, kiểm thử thành công có nghĩa là tìm ra lỗi. Nó cũng như TDD. Có lỗi có nghĩa là mọi thứ vẫn đã trong tiến trình, vì các bạn biết rằng bạn cần xử lý vấn đề.

TDD bảo vệ rằng hệ thống đáp ứng đúng yêu cầu, bạn có thể hoàn toàn lạc quan vào hệ thống.

TDD tập trung vào production để đảm bảo kiểm thử bao gồm xác. Kiểm thử truyền thống thì tập trung vào việc xây đắp test case.

Xem thêm: Hướng Dẫn Cách Làm Son Môi Handmade Tại Nhà Màu Đẹp An Toàn, Top 10 Cách Làm Son Môi Handmade Lên Màu Cực Đẹp

TDD, độ coverage là 100%. đông đảo dòng code những được test, không hệt như kiểm thử truyền thống.

Trong quy mô Agile, bạn nên “kiểm thử có mục đích”. Chúng ta nên biết tại sao bạn kiểm thử và mức độ kiểm demo là như vậy nào

5. Acceptance TDD với Developer TDD là gì?

Có 2 mức độ của TDD:

Acceptance TDD (ATDD) (kiểm test chấp nhận):với ATDD các bạn viết một kiểm test chấp nhận. Đoạn test này thỏa mãn nhu cầu yêu cầu của spec hoặc thỏa mãn nhu cầu hành vi của hệ thống. Kế tiếp thì viết code đầy đủ để thỏa mãn nhu cầu đoạn demo này. Kiểm thử chấp nhận tập trung vào hành vi toàn diện và tổng thể của hệ thống. ATDD còn gọi là Behavioral Driven Development (BDD).

Developer TDD:bạn viết chạy thử (unit test…) và viết code đủ để pass đoạn test đó. Unit test tập trung vào từng chức năng nhỏ dại của hệ thống. Developer TDD được call là TDD.

*

TDD đang mở rộng thông qua phát triển theo hướng quy mô Agile (AMDD)

TDD rất tốt trong việc chứng thực và đặc tả chi tiết. Nó không thành công xuất sắc trong việc nói tới thông qua những vấn đề lớn hơn hoàn toàn như là thiết kế tổng thể, sử dụng hệ thống hoặc giao diện người dùng. AMDD giải quyết và xử lý các vấn đề không ngừng mở rộng Agile mà lại TDD không giải quyết được.

Do kia AMDD được sử dụng cho những vấn đề lớn hơn.

So sánh TDD cùng với AMDD

Về TDD :

TDD rút ngắn thời hạn lập trìnhTDD sử dụng cho spec detailTDD đảm bảo an toàn chất lượng codeTDD sử dụng cho thiết kế viênTDD giới hạn chỉ làm việc phạm vi phần mềm

Về AMDD:

AMDD rút ngắn thời gian mô hình hóaAMDD vận dụng cho vụ việc quy tế bào lớnAMDD bảo đảm chất lượng liên lạc giữa developer và các bên liên quanAMDD dùng cho những nhà so sánh nghiệp vụ, stakeholder và nhân viên dữ liệuAMDD bao gồm phạm vi rộng hơn, bao hàm cả stakeholder, nhằm đào bới một dìm thứ chung6. Những lỗi thường gặp khi vận dụng TDDKhông cân nhắc các demo bị failQuên đi làm việc tối ưu sau khi viết code cho chạy thử passThực hiện về tối ưu code trong lúc viết code cho chạy thử pass => không nên như vậyĐặt tên các test cực nhọc hiểu và về tối nghĩaKhông ban đầu từ các test đơn giản nhất và không theo các baby step.Chỉ chạy mỗi test đang bị fail hiện tạiViết một demo với kịch phiên bản quá phức tạp7. Những ví dụ xem thêm về TDDPart I – Test-Driven Development by example – Kent Beck.8. Những công cố gắng hỗ trợ

cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit.

Kết Luận:

Bài viết này chỉ hi vọng giúp các bạn hiểu cơ bản về TDD bạn cần tham khảo thêm để có thể hiểu sâu hơn, thực hành giỏi về TDD với áp dụng công dụng nó vào công việc của bạn. Bạn có thể tham khảo website ở link tài liệu tham khảo dưới để có thể học và thực hành một cách xuất sắc nhất!

Tham khảo khóa huấn luyện lập trình web 6 tháng, đảm bảo 100% các bước đầu ra!

Tài liệu tham khảo:

https://www.guru99.com/test-driven-development.html

http://blog.co-mit.com/post/9/Tìm+hiểu+mô+hình+TDD+(Test+-+Driven+Development)+và+cách+áp+dụng