Best practices là gì

  -  

Chào gần như người! Trong nội dung bài viết này tôi xin trình bày những “Best Practices” cần biết khi cách tân và phát triển TDD.

Bạn đang xem: Best practices là gì

Bạn vẫn xem: Best practice là gì

“Best Practice” là tập hợp những kỹ thuật và giải pháp làm mà lại đã được nghiên cứu, minh chứng trong thực tế, khi áp dụng nó sẽ có tác dụng cho thành phầm của họ tốt hơn, kiêng được tương đối nhiều các vấn đề mà fan khác đã gặp mặt phải.

“Best Practice” mang đến TDD vẫn tập hợp các quy tắc mà bọn họ nên áp dụng khi viết TDD. Rõ ràng ở đó là tôi ra mắt việc viết TDD vào Java cùng Scala, nhưng thực chất chúng hoàn toàn có thể áp dụng trong đa số các ngôn ngữ. Tôi đã trình bè đảng các quy tắc theo số trang bị tự nhằm mọi bạn dễ nhớ.

Các quy tắc dùng trong cách tân và phát triển TDD

1. Tách biệt thân phần kiểm tra và code

Ưu điểm: Giúp quản lý code thuận tiện hơn, tách bóc biệt giữa phần code và test


*

Chúng ta cần có ít nhất 2 folder một đến code với một mang đến test. Ví dụ như trong scala + play2 rất có thể đặt code trong project/app, demo trong project/test. Ngoài việc giúp cai quản code dễ dãi hơn, đây còn là yêu cầu của không ít công cụ thống trị source code

2. Tên package như là nhau thân test code & source code

Ưu điểm: góp tìm demo code thuận tiện hơn

Khi kiểm tra code được tổ chức giống hệt như source code sẽ giúp tìm test code thuận lợi hơn với ngược lại. Điều này rất có ý nghĩa sâu sắc trong các dự án mập với hàng nghìn file code và test code.

3. Đặt tên class test dựa trên file code

Ưu điểm: tìm file test code dễ dàng hơn, đặc biệt là khi đề xuất tim file chạy thử cho một tệp tin code thay thể.

Xem thêm: Big Update ThÁNg 8, Zombie Nano ChÍNh ThỨC CẬP BẾN!


*

Trong những dự án lớn, con số các tệp tin code khôn xiết lớn. Lúc ấy nếu các file test không chọn cái tên theo một quy tắc làm sao đó sẽ khá khó search file test code. Để giải quyết và xử lý vấn đề này thì một quy tắc thường dùng là, đánh tên class test bao hàm tên class đề nghị test và hậu tố “Test” hoặc “Spec” sống cuối. Lấy ví dụ ta bao gồm class rất cần phải viết demo là ApplicationController.scala, class thử nghiệm sẽ là ApplicationControllerTest.scala hoặc ApplicationControllerSpec.Scala

4. Đặt tên cách thức test tế bào tả không hề thiếu ý nghĩa

Ưu điểm: Giúp hiểu đầy đủ ý nghĩa của cách làm test cơ mà không yêu cầu xem comment

Có hết sức nhiều cách để đặt tên thử nghiệm method. Cơ mà cách rất được yêu thích là để tên dùng Given/When/Then trong định nghĩa của BDD. Given – giới thiệu điều kiện, When – biểu đạt hành động, Then – tế bào tả công dụng mong đợi. Nếu một số test không tồn tại điều kiện trước, thì Given hoàn toàn có thể bỏ qua

Bên dưới là 1 ví dụ của để tên:

Test public final void whenSemicolonDelimiterIsSpecifiedThenItIsUsedToSeparateNumbers() …

5. Viết test trước lúc viết code

Ưu điểm: Đảm bảo rằng test code luôn được viết

Bằng phương pháp viết hoặc sửa đổi kiểm tra code trước khi viết, người trở nên tân tiến sẽ triệu tập hơn vào yêu ước trước khi bước đầu code. Điều này là điểm khác hoàn toàn lớn nhất so với bài toán viết test sau khoản thời gian viết code. Không chỉ có vậy việc viết thử nghiệm trước giúp chúng ta tăng chất lượng của test code, tránh vấn đề viết kiểm tra một biện pháp qua loa.

6. Chạy tất cả các demo mỗi lần đổi khác code

Ưu điểm: Đảm nói rằng không bao gồm lỗi xẩy ra khi do biến đổi code


*

Mỗi lần nạm đổi ngẫu nhiên phần như thế nào trong code, dù khủng hay nhỏ, ta cũng cần được chạy lại tất cả các test. Một bí quyết lý tưởng thì các test rất có thể chạy cấp tốc ngay trên vật dụng của người cải cách và phát triển để họ không phải đợi thừa lâu. Mọi khi code được chuyển lên git hoặc svn, yêu cầu chạy các test lại để đảm bảo rằng không tồn tại vấn đề gây ra do merge code. Điều này quan trọng đặc biệt quan trọng khi có khá nhiều người thuộc tham gia cách tân và phát triển code. Rất có thể setup các bước này một cách tự động hóa dùng các phần mềm như Jenkins, Hudson để thiết đặt trên client

7. Kiểm soát code(Refactor) chỉ sau khi tất cả test đang thành công

Ưu điểm: quá trình kiểm tra code đang an toàn, không bị kiểm tra các phần code bị lỗi

Nếu tất cả test chạy thành công thì nó tương đối an toàn để soát sổ code. Sau khi refactor code thì không nhất thiết phải viết thêm chạy thử mới, cơ mà sẽ đề nghị sửa đổi demo code cho hầu hết phần đã cố đổi. Điều kiện ưng ý là, sau thời điểm refactor thì tất cả các thử nghiệm chạy các thành công

8. Hạn chế sự nhờ vào giữa những test

Ưu điểm: Test rất có thể chạy hòa bình mà không nhờ vào vào những test khác

Mỗi thử nghiệm nên tự do từ các test khác. Người cải tiến và phát triển nên hoàn toàn có thể thực thi ngẫu nhiên phương thức test nào đó, hoặc một tập những test độc lập. Nếu bao gồm sự nhờ vào từ những test thì bọn chúng dễ bị tác động khi viết các test mới.

9. Những test đề xuất chạy nhanh

Ưu điểm: các test được sử dụng thường xuyên, đề xuất test chạy nhanh sẽ tằn tiện thời gian

Nếu test chạy mất không ít thời gian, người cải cách và phát triển sẽ dễ ợt dừng bọn chúng hoặc chỉ chạy một tập nhỏ tuổi của các test liên quan tới phần chúng ta sắp cố kỉnh đổi. Cụ thể điều này là không tốt vì không thể bảo vệ tất cả những test sẽ thành công xuất sắc khi viết test bắt đầu hoặc code mới. Tác dụng từ chạy nhanh là sát bên việc để dành thời gian, nó còn giúp phát hiện những vấn đề sớm và hoàn toàn có thể giải quyết vụ việc sớm.

Xem thêm: Game Tô Màu : Bé Tập Vẽ Tranh

10. Cần sử dụng các đối tượng người sử dụng dữ liệu đưa (mocks)

Ưu điểm: sút sự nhờ vào vào code, test chạy cấp tốc hơn

Mock là vấn đề kiện quan trọng để làm cho các test cấp tốc hơn bời bởi phương thức thử nghiệm không cần liên kết và chờ lấy tài liệu từ các đối tượng người sử dụng bên ngoài, toàn bộ dữ liệu cần thiết đã được hỗ trợ trong đối tượng người tiêu dùng mock. Nó cũng giúp người cải tiến và phát triển tập trung hơn vào phần test mà họ đang viết ko cần để ý đến các đối tượng cung ứng dữ liệu. Có tương đối nhiều công cụ cung ứng tạo ra các đội trượng mock lúc viết unit test, ví dụ như: mockito, …

11. Dùng setup và tear-down phương thức

Ưu điểm: mang đến phép thiết lập dữ liệu trước khi chạy kiểm tra và reset dữ liệu sau khoản thời gian test chạy xong

12. Tiêu giảm dùng base class

Ưu điểm: khiến cho class chạy thử rõ ràng

Class chạy thử cần rõ ràng và mạch lạc, dó đó bọn họ nên giảm bớt dùng base class lúc viết unit test.

13. Dùng các công gắng để cung cấp test

Ưu điểm: Đo các thông số liên quan cho test, triển khai test một giải pháp tự động

Code Coverage: Là phép tắc đo xác suất code được thử nghiệm trong dự án. Hoàn toàn có thể dùng một trong các tool như SonarQuebe, Clover. Những công gắng này cung cấp hầu hết những ngôn ngữ

CI – Continuous integration (CI): Tool để triển khai các thao tác auto theo một kế hoạch lập từ bỏ trước đó. Rất có thể dùng các công nắm như: Jenkins, Hudson