Kiến thức cơ bản về TDD( Test Driven Development )

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

TDD là cách tăng trưởng ứng dụng từ Test case, Test case sẽ được viết trước để xác lập những nhu yếu cơ bản cần có. Nói cách khác, Test case cho từng tính năng sẽ được tạo để kiểm tra trước khi code, nếu Test case fail thì development sẽ check và update code để pass được Test case đã tạo trước đó. Mục đích chính của TDD là viết code rõ ràng, đơn thuần và ít lỗi .TDD khởi đầu bằng việc phong cách thiết kế và viết test cho mọi tính năng nhỏ của ứng dụng. Theo cách tiếp cận TDD, tiên phong là test sẽ được viết để validate đoạn code sẽ làm cái gì, làm đúng hay chưa .

Ở quy trình kiểm thử phần mềm thông thường, chúng ta viết code rồi mới viết test. Test có thể lỗi vì test sau khi yêu cầu đã được code xong. Để pass đoạn test này thì developer phải refactor lại code.

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

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

TDD là một tiến trình tăng trưởng và kiểm thử tự động hóa trước khi thực sự bắt tay vào tăng trưởng ứng dụng ( nôm na là trước khi code ). Bởi thế mà TDD đôi lúc còn được gọi với cái tên Test First Development

2. Ứng dụng TDD như thế nào?

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

  1. Tạo test
  2. Chạy test và check xem có lỗi hay không
  3. Viết code
  4. Chạy test và refactor code (đương nhiên là refactor để pass test)
  5. Lặp lại các bước trên

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

  1. Viết test
  2. Chạy test
  3. Sửa code để test chạy đúng
  4. Lặp lại 3 bước trên

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

  1. TDD không phải tập trung về testing hay là về design
  2. TDD không có nghĩa là “viết các kịch bản test rồi xây dựng một hệ thống sao cho nó pass các kịch bản test này “
  3. TDD không có nghĩa là test nhiều hơn

4. TDD Với Testing truyền thống

Cách tiếp cận kiểu TDD là một kỹ thuật đặc biệt quan trọng. Nó bảo vệ rằng mã nguồn của bạn luôn được kiểm tra kỹ lưỡng ở mức độ xác nhận ( confirm input / output )Với kiểm thử truyền thống cuội nguồn, kiểm thử thành công xuất sắc có nghĩa là tìm ra lỗi. Nó cũng giống như TDD. Có lỗi tức là mọi thứ vẫn đang trong tiến trình, vì bạn biết rằng bạn cần xử lý yếu tố .TDD bảo vệ rằng mạng lưới hệ thống phân phối đúng nhu yếu, bạn hoàn toàn có thể trọn vẹn tự tin vào mạng lưới hệ thống .TDD tập trung chuyên sâu vào production để bảo vệ kiểm thử đúng mực. Kiểm thử truyền thống cuội nguồn thì tập trung chuyên sâu vào việc phong cách thiết kế test case .TDD, độ coverage là 100 %. Mọi dòng code đều được test, không giống như kiểm thử truyền thống lịch sử .Trong quy mô Agile, bạn nên “ kiểm thử có mục tiêu ”. Bạn nên biết tại sao bạn kiểm thử và mức độ kiểm thử là ra làm sao

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

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

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

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

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

TDD rất tốt trong việc xác nhận và đặc tả cụ thể. Nó không thành công xuất sắc trong việc nói đến trải qua những yếu tố lớn hơn như phong cách thiết kế tổng thể và toàn diện, sử dụng mạng lưới hệ thống hoặc giao diện người dùng. AMDD xử lý những yếu tố lan rộng ra Agile mà TDD không xử lý được .Do đó AMDD được sử dụng cho những yếu tố lớn hơn .

So sánh TDD với AMDD

Về TDD :

  • TDD rút ngắn thời gian lập trình
  • TDD dùng cho spec detail
  • TDD đảm bảo chất lượng code
  • TDD dùng cho lập trình viên
  • TDD giới hạn chỉ ở phạm vi phần mềm

Về AMDD:

  • AMDD rút ngắn thời gian mô hình hóa
  • AMDD áp dụng cho vấn đề quy mô lớn
  • AMDD đảm bảo chất lượng liên lạc giữa developer và các bên liên quan
  • AMDD dùng cho các nhà phân tích nghiệp vụ, stakeholder và chuyên viên dữ liệu
  • AMDD có phạm vi rộng hơn, bao gồm cả stakeholder, nhằm hướng đến một nhận thứ chung

6. Các lỗi thường gặp khi áp dụng TDD

  • Không quan tâm đến các test bị fail
  • Quên đi thao tác tối ưu sau khi viết code cho test pass
  • Thực hiện tối ưu code trong lúc viết code cho test pass => không nên như vậy
  • Đặt tên các test khó hiểu và tối nghĩa
  • Không bắt đầ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ại
  • Viết một test với kịch bản quá phức tạp

7. Các ví dụ tham khảo về TDD

  • Part I – Test-Driven Development by example – Kent Beck .
  • Part III – Test-Driven Development : A practical guide – David Astels .

    Các bạn có thể đọc tham khảo 1 ví dụ chi tiết tại bài viết sau:
    https://phambinh.net/bai-viet/tdd-la-gi-code-it-bug-hon-voi-tdd/

8. Các công cụ 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ỉ kỳ vọng giúp những bạn hiểu cơ bản về TDD Bạn cần tìm hiểu và khám phá thêm để hoàn toàn có thể hiểu sâu hơn, thực hành thực tế tốt về TDD và vận dụng hiệu suất cao nó vào việc làm của bạn. Bạn hoàn toàn có thể tìm hiểu thêm Website ở link tài liệu tìm hiểu thêm bên dưới để hoàn toàn có thể học và thực hành thực tế một cách tốt nhất !

Tài liệu tham khảo:

https://www.guru99.com/test-driven-development.htmlhttps://phambinh.net/bai-viet/tdd-la-gi-code-it-bug-hon-voi-tdd/http://blog.co-mit.com/post/9/Tìm+hiểu+mô+hình+TDD+(Test+-+Driven+Development)+và+cách+áp+dụng

Rate this post
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments