Gần đây, tôi đã xem một cuộc nói chuyện của Ian Cooper từ NDC 2013 với chủ đề “TDD nơi mà đã làm cho tất cả trở nên sai sót”, và điều này đã hoàn toàn thay đổi cách mà tôi nhìn nhận về kiểm thử đơn vị. Bài đăng này tập trung về cách tôi nhìn nhận sai về  nó, những lợi ích mà phương pháp tiếp cận của Ian mang lại sau đây:

Phương pháp dựa trên kiểm thử  đơn vị – là sai…

Tôi luôn thực hiện việc kiểm thử với các hàm và đưa ra những dữ liệu giả lập nhằm kiểm tra các kết quả của các hàm. Không có  nghi ngờ gì về những lợi ích tiếp cận này, ví dụ:

-Giúp xác định lỗi sớm

-Đem lại sự tự tin để re-factor bên trong phương pháp

-Giúp xác định nơi mà một thay đổi có thể phá vỡ sự tồn tại hành vi bên trong phương pháp

Tất cả những điều này thật sự tuyệt vời nhưng tôi cũng có kinh nghiệm và được sống chung với những vấn đề sau:

– Việc kiểm thử được gắn kết chặt chẽ với sự thực thi để ngăn chặn re-factor bên ngoài của phương pháp

– Bất kì những kết quả lớn trong kiểm thử re-factor và vì thế loại bỏ được sự tự tin và chi phí thời gian

– Việc kiểm thử không bao phủ hết “sự kết nối” giữa các lớp(class) trong API cộng đồng thông qua tất cả các lớp logic của bạn

Những chuỗi cuộc đối thoại gần đây tổ chức bởi Martin Fowler với chủ đề “TDD bị chết”, được nghe  David Heinemeier Hansson nói về “Sự thiệt hại trong thiết kế kiểm thử gây ra”, đang nổi bật là vấn đề kiểm thử đó thường có thể  dẫn tới những thiết kế nghèo nàn. Tôi đã lặp lại những cơ hội tạo ra những phương pháp cộng đồng rằng điều đó nên là riêng tư, và chỉ là ảo khi không cần đến, sẽ thích hợp hơn khi được di chuyển một cách logic đến một nơi nào  đó, và tạo ra nhiều hơ approachn sự lựa chọn trong các thiết kế nghèo nàn để đáp ứng nhu cầu kiểm thử đơn vị cho mỗi phương pháp cá nhân trong sự cô lập của tất cả những thứ khác.

Tôi thành thật đã nghĩ về những điều này nơi mà có những thứ tôi phải sống để có được những lợi ích trong việc kiểm thử đơn vị và TDD. Oh cách mà tôi đã làm đã sai …

API dựa trên việc kiểm thử đơn vị là đúng…

Suốt cuộc nói chuyện của Ian anh ấy đã thuyết phục tôi rằng tôi đã hiểu nhầm về thuật ngữ “Unit”(đơn vị), khi mà nói về kiểm thử đơn vị. Tôi luôn luôn nghĩ rằng bạn nên kiểm tra đơn vị nhỏ nhất có thể trong sự cô lập hoàn toàn (phương pháp dựa trên kiểm thử đơn vị ). Tuy nhiên, anh ấy đã phát biểu rằng một kiểm thử đơn vị nên nhắm đến mục tiêu một đơn vị của hành vi được xác định bởi nhu cầu kinh doanh.

Với sự hiểu biết của một đơn vị không còn là một nhu cầu kiểm thử bên trong, và Ian phát biểu chúng ta nên kiểm thử các API công cộng. Các API đại diện cho các hợp đồng bạn có với các doanh nghiệp (những gì mà code của bạn được mong đợi để thực hiện ) và không thể thay đổi , làm cho nó trở thành một nơi hoàn hảo cho một kiểm thử đơn vị.

Chúng tôi đã chuyển sang sự tiếp cận này trong dự án hiện tại mà chúng tôi đang làm và sự thay đổi/sự giải phóng tôi đã cảm thấy khi mà re-factoring không được tin tưởng. Bây giờ tôi có thể tiến hành với quy mô lớn re-factor mà không có bất kì nhu cầu nào để cập nhật hay xóa các kiểm thử của tôi,  và tiếp tục với sự tự tin khi bộ kiểm thử của tôi đạt yêu cầu; tất cả trong trong lượng thời gian được giảm dần. Lợi ích của những việc này không thể được hiểu, nó giúp những nhà phát triển khả năng để làm việc với sự tự tin và tự do, trong khi không có quản lý kiểm thử ở trên hay việc ghi lại.

Tôi cũng tin tưởng phương pháp tiếp cận này giảm một số vấn đề mà David đã làm nổi bật trong blog của anh ấy với bài viết “Sự thiệt hại trong thiết kế kiểm thử gây ra “. Đừng làm cho tôi phải sai, chúng tôi vẫn có các kho lưu trữ tồn tại  dành cho một mục đích duy nhất với việc kiểm thử đơn vị. Tôi thực hiện tuy nhiên cảm thấy có thể để thiết kế và thực thi sự logic cốt lõi trong doanh nghiệp cùng với sự tự do hoàn toàn. Tôi cũng tin tưởng trong tương lai nhu cầu về kho lưu trữ có thể được loại bỏ việc sử dụng công cụ như Entity Framework.

 Tôi đã thực hiện một vài việc liên quan lúc đầu với phương pháp tiếp cận này:

– Điều này sẽ không dẫn tới việc thiết lập rộng lớn?

– Sẽ không có nhiều kiểm thử sai sót nếu bạn phá võ một số thứ hơn là chỉ một?

– Những gì mà code được chia sẻ , tôi có kiểm thử nó hai lần? 

Đây là tất cả các điểm có giá trị, mặc dù bây giờ tôi thử phương pháp tiếp cận này mặc dù chúng không tệ bằng những cái đầu đã xuất hiện:

– Việc thiết lập đã tạo ra không ở bất cứ nơi đâu gần kích cỡ mà tôi mong đợi, bởi vì tôi không phải Chế giễu mọi thứ.

–Vâng tôi vẫn nghĩ nhiều kiểm thử sẽ sai, nhưng ai quan tâm điều này. Đó là vấn đề và tôi biết điều này, đó là một điều quan trọng. 

– Vâng việc kiểm thử hai lần, nếu nó không là API cộng đồng khác, sau đó làm lại. Điều này cho phép bạn tự tin re-factor một trong các API.

Một chú ý cuối cùng, nếu bạn đang viết những kiểm thử đơn vị bằng một phương pháp/ cấp độ nội bộ, sau đó xem cuộc nói 

Nguồn bài viết : frankcode.wordpress.com