Tại sao kiểm tra tự động liên tục thất bại trong công ty của tôi?

Chúng tôi đã cố gắng giới thiệu thử nghiệm tự động cho nhà phát triển nhiều lần tại công ty của tôi. Nhóm QA của chúng tôi sử dụng Selenium để tự động hóa các bài kiểm tra UI, nhưng tôi luôn muốn giới thiệu các bài kiểm tra đơn vị và kiểm tra tích hợp. Trong quá khứ, mỗi lần chúng tôi thử nó, mọi người đều cảm thấy phấn khích trong một hoặc hai tháng đầu tiên. Sau đó, vài tháng, mọi người chỉ cần ngừng làm việc đó.

Một vài quan sát và câu hỏi:

1. Kiểm thử tự động có thực sự hoạt động không? Hầu hết các đồng nghiệp của tôi, những người từng làm việc tại các công ty khác đã cố gắng và không thực hiện được chiến lược thử nghiệm tự động. Tôi vẫn chưa thấy một công ty phần mềm thực tế nào sử dụng nó và không chỉ nói về nó. Vì vậy, nhiều nhà phát triển xem thử nghiệm tự động là một thứ gì đó tuyệt vời trên lý thuyết nhưng không hoạt động trong thực tế. Đội ngũ kinh doanh của chúng tôi sẽ yêu thích các nhà phát triển thực hiện nó ngay cả với chi phí thêm 30% thời gian (ít nhất là họ nói như vậy). Nhưng các nhà phát triển là những người hoài nghi.

2. Không ai thực sự biết làm thế nào để kiểm tra tự động đúng cách. Vâng, tất cả chúng ta đều đã đọc các ví dụ thử nghiệm đơn vị trên internet, nhưng sử dụng chúng cho một dự án lớn là một cái gì đó khác hoàn toàn. Thủ phạm chính là chế nhạo / khai thác cơ sở dữ liệu hoặc bất cứ thứ gì khác không tầm thường. Bạn cuối cùng dành nhiều thời gian chế giễu hơn là viết các bài kiểm tra thực tế. Sau đó, khi bắt đầu mất nhiều thời gian hơn để viết bài kiểm tra hơn mã, đó là khi bạn từ bỏ.

3. Có bất kỳ ví dụ hay về kiểm tra đơn vị / kiểm tra tích hợp hệ thống được sử dụng trong một ứng dụng web tập trung dữ liệu phức tạp không? Bất kỳ dự án nguồn mở nào? Ứng dụng của chúng tôi là trung tâm dữ liệu nhưng cũng có nhiều logic miền. Tôi đã thử cách tiếp cận kho lưu trữ tại một số điểm và thấy nó khá tốt cho thử nghiệm đơn vị, nhưng nó có giá để có thể tối ưu hóa truy cập dữ liệu một cách dễ dàng và nó đã thêm một lớp phức tạp khác.

Chúng tôi có một dự án lớn được thực hiện bởi 20 nhà phát triển có kinh nghiệm. Đây dường như là một môi trường lý tưởng để giới thiệu thử nghiệm đơn vị / thử nghiệm tích hợp.

Tại sao nó không làm việc cho chúng ta? Làm thế nào bạn làm cho nó làm việc tại công ty của bạn?

Phần khó nhất khi làm bài kiểm tra đơn vị là lấy kỷ luật để viết bài kiểm tra trước / sớm. Hầu hết các nhà phát triển được sử dụng để chỉ đi sâu vào mã. Nó cũng làm chậm quá trình phát triển từ rất sớm khi bạn đang cố gắng tìm ra cách viết một bài kiểm tra cho mã. Tuy nhiên, khi bạn trở nên tốt hơn khi thử nghiệm, điều này sẽ tăng tốc. Và do các bài kiểm tra viết, chất lượng ban đầu của mã bắt đầu cao hơn.

Khi bắt đầu, hãy thử chỉ để viết bài kiểm tra. Đừng lo lắng quá nhiều về việc chế giễu / sơ khai mọi thứ ngay từ đầu. Giữ các bài kiểm tra đơn giản. Các thử nghiệm là mã và có thể / nên được tái cấu trúc. Mặc dù dọc theo những dòng đó nếu một cái gì đó khó kiểm tra, nó cũng có thể là thiết kế. TDD hướng tới việc sử dụng hầu hết các mẫu thiết kế (theo kinh nghiệm của tôi, đặc biệt là mẫu Factory).

Hãy chắc chắn rằng các bài kiểm tra có được mức độ hiển thị. Tích hợp chúng trong quá trình phát hành, trong quá trình xem xét mã hỏi về chúng. Bất kỳ lỗi tìm thấy nên được kiểm tra. Những điều này là nơi TDD tỏa sáng.

Dưới đây là một số tài nguyên mà tôi thấy hữu ích:

http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

http://www.agitar.com/doads/TheWayOfTestivus.pdf

Biên tập:

Một điều cần lưu ý khi bạn đang viết bài kiểm tra. Bạn không cố gắng chỉ định bất cứ điều gì về việc triển khai mã, chỉ hành vi. Khi bạn viết mã, bạn kiểm tra nó mọi lúc. Cố gắng thực hiện nó với các câu lệnh gỡ lỗi và như vậy. Bài kiểm tra viết chính thức hóa điều này và cung cấp một bản ghi các bài kiểm tra mà bạn có. Bằng cách đó, bạn có thể kiểm tra chức năng của mình một cách tự tin mà không vô tình bỏ qua một trường hợp thử nghiệm mà bạn đã nhớ được giữa quá trình phát triển.

Theo nhiều cách tôi đồng ý với nhóm của bạn.

1. Hầu hết các bài kiểm tra đơn vị là nghi vấn về giá trị. Vì phần lớn các bài kiểm tra dường như quá đơn giản.

2. Viết mã kiểm tra tốt khó hơn nhiều so với chỉ viết mã. Có một tỷ lệ lớn cộng đồng nhà phát triển tin rằng chỉ cần làm cho nó hoạt động, so với chất lượng mã / thiết kế. Và một tỷ lệ thậm chí còn lớn hơn, những người thậm chí không biết mã chất lượng là gì.

3. Có thể mất nhiều thời gian hơn để viết mã kiểm tra đơn vị so với mã thực tế.

4. Tìm ra cách kiểm tra đầy đủ mã phức tạp hơn (ví dụ: thứ bạn thực sự quan tâm để kiểm tra kỹ lưỡng) nằm ngoài khả năng của nhiều nhà phát triển.

5. Duy trì kiểm tra đơn vị mất quá nhiều thời gian. Những thay đổi nhỏ có thể có hiệu ứng gợn lớn. Mục tiêu chính của kiểm tra đơn vị tự động là tìm hiểu xem các thay đổi có phá vỡ mã không. Tuy nhiên, 99% thời gian kết thúc việc phá vỡ là các bài kiểm tra chứ không phải mã.

Với tất cả các vấn đề trên, vẫn không có cách nào tốt hơn để có thể thực hiện thay đổi mã và có một số mức độ tin cậy rằng một cái gì đó đã không phá vỡ một cách không tốn kém hơn là tự động hóa các bài kiểm tra của bạn.

Một số trong những điều trên có thể được giảm bớt ở một mức độ nào đó bằng cách không đi theo sách giáo khoa kiểm tra đơn vị.

Nhiều loại thiết kế / ứng dụng được kiểm tra tốt hơn bằng cách tự động kiểm tra ở cấp độ mô-đun / gói. Theo kinh nghiệm của tôi, hầu hết các lỗi mã hóa không phải do mã trong một lớp được mã hóa không chính xác mà bởi vì người viết mã không hiểu làm thế nào lớp của họ được cho là làm việc với các lớp khác. Tôi đã thấy rất nhiều tiếng nổ cho loại thử nghiệm này. Nhưng một lần nữa, các bài kiểm tra này khó viết hơn các bài kiểm tra đơn vị (cấp lớp).

Nó thực sự nắm rõ liệu các nhà phát triển có tin vào quá trình này hay không. Nếu họ làm như vậy, thì họ sẽ viết bài kiểm tra đơn vị tốt, sớm tìm ra lỗi và là người đề xuất. Nếu họ không làm như vậy, thì các bài kiểm tra đơn vị của họ sẽ vô dụng và sẽ không tìm thấy bất kỳ lỗi nào và lý thuyết về các bài kiểm tra đơn vị của họ là vô ích sẽ được chứng minh là đúng (trong suy nghĩ của họ).

Điểm mấu chốt là tôi chưa bao giờ thấy phương pháp thử nghiệm đơn vị tự động hoàn toàn hoạt động trong hơn một vài tháng, nhưng ý tưởng về thử nghiệm đơn vị tự động vẫn tồn tại mặc dù chúng tôi chọn lọc những gì thực sự cần thử nghiệm. Cách tiếp cận này có xu hướng ít chỉ trích hơn và được tất cả các nhà phát triển chấp nhận hơn là chỉ một số ít.

Thủ phạm chính là chế nhạo / khai thác Cơ sở dữ liệu hoặc bất cứ điều gì không đơn giản.

Và có vấn đề của bạn.

Mọi người đều đưa ra những quan điểm tốt về cách tích hợp kiểm tra đơn vị vào môi trường của bạn. Làm thế nào để buộc mọi người làm điều đó đủ để họ thấy giá trị thực tế và nó "dính". Nhưng nếu nó cực kỳ đau đớn để làm, và / hoặc không mang lại lợi ích gì, nó sẽ không dính vào.

Sơ khai cơ sở dữ liệu nên chết đơn giản. Thay vì giao diện của bạn chuyển đến một số sao lưu DB để cung cấp kết quả của nó, bạn đặt một đối tượng được mã hóa đơn giản. Nếu bạn không thể làm điều đó, thì thiết kế / kiến ​​trúc của bạn có vấn đề. Mã của bạn giả định rằng nó sẽ đến cơ sở dữ liệu hoặc bạn không có sự trừu tượng hóa giao diện để thay đổi nó.

Đây không chỉ đơn giản là một mối quan tâm kiểm tra / chất lượng. Ngay khi bạn muốn thay đổi nhà cung cấp DB hoặc thay vào đó, hoặc hỗ trợ các ứng dụng di động không được kết nối, thiết kế của bạn không thành công. Nếu bạn không thể hỗ trợ các trường hợp linh hoạt đơn giản nhất, bạn chắc chắn không thể hỗ trợ những điều phức tạp hơn mà doanh nghiệp của bạn chắc chắn sẽ yêu cầu.

Bạn cần bắt đầu với một cái gì đó nhỏ, đơn giản để tự động hóa và giá trị cao. Kéo xuống một số trái cây ngọt ngào, treo thấp, và bạn sẽ có thể bán quá trình. Chỉ ra cách nó cứu ai đó vào một đêm muộn hoặc một cuộc gọi cuối tuần. Sau đó, bạn có thể mở rộng ra từ đó.

Để thực hiện kiểm tra tự động tốt, bạn cần một người là tài nguyên và nhà truyền giáo, và người đã mua từ các cấp quản lý cao hơn.

Đối xử với sự phát triển thử nghiệm tự động của bạn như bất kỳ dự án nhanh nào khác. Sản xuất thử nghiệm hoàn thành một cách thường xuyên.

Thêm từ nhận xét: Đó là nhiều hơn một vấn đề quản lý. Là mã được coi là "thực hiện" trước khi nó được ghi lại? Trước khi nó được kiểm tra? Trước khi nó bao gồm và vượt qua các bài kiểm tra đơn vị?

Làm thế nào bạn tiếp cận điều này thực sự phụ thuộc vào vai trò của bạn. Bạn có phải là đồng nghiệp? Nếu vậy, hãy chỉ cho người khác cách nó giúp mã của bạn dễ dàng sử dụng lại và duy trì. Bạn có phải là người dẫn đầu? Chọn lập trình viên của bạn có nhiều vấn đề về mã nhất và giúp họ thêm các bài kiểm tra để tránh những vấn đề đó. Bạn có phải là ông chủ? Đặt nó làm tiêu chuẩn rằng "mã không được thực hiện cho đến khi các bài kiểm tra đơn vị được thực hiện.

Thực hiện theo các quy tắc cơ bản. Các xét nghiệm:

1. phải chạy thường xuyên! Bạn có thể thực hiện các bài kiểm tra chạy trên mọi bản dựng, trước / sau mỗi lần đăng ký hoặc chỉ mỗi sáng. Tự động kích hoạt là rất thích hợp để kích hoạt bằng tay. Bởi vì trong lý thuyết, bạn có thể yêu cầu mọi người trong nhóm chịu trách nhiệm đảm bảo họ chạy thử nghiệm, nếu nó không được tự động hóa, điều đó có thể không xảy ra thường xuyên! Và nếu bạn không chạy thử nghiệm của mình đủ thường xuyên, cả hai đều phát hiện ra lỗi quá muộn khuyến khích rất nhiều thử nghiệm bị hỏng, dẫn đến điểm 2:

2. Bạn vẫn sẽ chỉ thành công nếu những bài kiểm tra đó, hiện đang chạy thường xuyên, không cản trở . Theo đó, chúng tôi có nghĩa là các bài kiểm tra:

   a. không được mất quá nhiều thời gian để chạy (chủ quan) cho giá trị họ cung cấp! Làm cho bài kiểm tra của bạn rực sáng nhanh chóng. Đừng để mọi người kiểm tra các bài kiểm tra sẽ lãng phí thời gian của bạn để cho họ chạy!

   b. không được không đáng tin cậy Tránh các bài kiểm tra đa luồng nếu có thể. Áp dụng thực hành kỹ thuật cho các thử nghiệm của bạn giống như mã khác của bạn: đặc biệt - mã xem lại các thử nghiệm của bạn!

   c. không được khó sửa chữa và bảo trì hơn mã thực tế được kiểm tra. Vận tốc mã hóa của bạn sẽ thực sự hấp dẫn nếu một dòng nhỏ thay đổi thành cơ sở mã của bạn yêu cầu bạn sửa 10 bài kiểm tra khác nhau.

Và cuối cùng, quy tắc số 3. Các thử nghiệm không chỉ không cung cấp giá trị âm, như trong quy tắc 2, chúng phải cung cấp giá trị dương. Các xét nghiệm ...

3. thực sự phải nói với bạn điều gì đó bạn quan tâm khi họ thất bại! (Không có bài kiểm tra nào có thông báo lỗi tối nghĩa hoặc chỉ đưa ra cho bạn những khiếu nại vô lý như 'bạn quên chạy thử nghiệm trên máy Windows 2008', làm ơn!).

Một cách phổ biến để vi phạm quy tắc số 3 là kiểm tra điều sai . Điều này đôi khi là do một bài kiểm tra quá lớn hoặc quá không tập trung. Nhưng thông thường, nó xuất phát từ việc không kiểm tra thứ gì đó mà khách hàng sẽ quan tâm và kiểm tra các chi tiết triển khai không liên quan. (Nhưng đôi khi kiểm tra chi tiết triển khai cũng tạo ra một thử nghiệm hiệu quả - IMO chỉ cần thực hành quyết định cái nào.)

Kết luận: những quy tắc cơ bản này chỉ cho bạn theo hướng chung của một kỷ luật kiểm tra bền vững , đó là điều bạn đang khao khát một cách tuyệt vọng. Khi kiểm tra, hãy tự hỏi nếu thử nghiệm này thực sự bền vững và có thể duy trì. Nhớ lại:

• nếu các xét nghiệm không bền vững, chúng sẽ rơi vào tình trạng không sử dụng được và do đó trở nên lãng phí công sức
• nếu các bài kiểm tra không bền vững, bạn sẽ ngừng thực hiện các bài kiểm tra và nhóm của bạn sẽ ngừng kiểm tra tốt hơn! Và, điểm cuối cùng:

Kiểm tra thực sự khó khăn. Bạn nên kỳ vọng rằng các bài kiểm tra của nhóm bạn về cơ bản sẽ hút khi bạn bắt đầu viết bài kiểm tra . Đừng nản lòng. Đừng vứt bỏ các bài kiểm tra cũ, bất cứ khi nào bạn nhận thấy chúng hút và không bền vững.

1. Nó thực sự hoạt động?

Vâng, nó làm - nếu được thực hiện đúng. Vấn đề là người kiểm tra cần điều chỉnh và mở rộng các tập lệnh tự động của họ sau khi các kỹ sư triển khai các tính năng mới.

2. Không ai thực sự có kinh nghiệm hoặc biết làm thế nào để kiểm tra tự động đúng cách.

Nhận một nhà tư vấn (một người biết làm thế nào nó được thực hiện đúng). Hoặc, đầu tư thêm thời gian. Thay thế là có nhóm thử nghiệm lớn hơn, những người thực hiện thử nghiệm tương tự bằng tay (dễ bị lỗi).

3.Chúng tôi có một dự án lớn với 20 nhà phát triển có kinh nghiệm làm việc về nó. Vì vậy, nó phải là một môi trường tuyệt vời để giới thiệu thử nghiệm đơn vị / thử nghiệm tích hợp. Tại sao nó không làm việc cho chúng ta? Làm thế nào bạn làm cho nó hoạt động trong công ty của bạn?

Tôi sẽ không gọi họ là "nhà phát triển có kinh nghiệm tốt", nếu họ từ chối làm các bài kiểm tra đơn vị. Có rất nhiều bài viết tuyệt vời về những lợi ích tích cực của thử nghiệm (cả thử nghiệm đơn vị và tích hợp), và cuối cùng, nó hiểu rõ chi phí của một công ty là bao nhiêu . Ví dụ, tôi làm việc trong một công ty nơi chất lượng là vấn đề, do đó, các bài kiểm tra đơn vị và tích hợp là không thể tránh khỏi. Bạn có thể dễ dàng tìm thấy rất nhiều bài báo cho biết rằng các bài kiểm tra đơn vị chỉ giảm 30% số lỗi! (Trên thực tế, nó nằm trong khoảng 20-90%, trung bình 30%, nhưng nó vẫn còn rất nhiều.)

Để làm cho nó hoạt động trong công ty của bạn, hoặc thuê một nhà tư vấn, hoặc giao nhiệm vụ này cho một kỹ sư cao cấp (sẽ mất một thời gian để làm việc đó). Và sau đó, buộc mọi người phải tuân theo các quy tắc.

Chúng có nhiều lý do tại sao giới thiệu thử nghiệm tự động có thể thất bại. Tôi nghĩ rằng điều này làm cho thực tế rằng các lập trình viên có xu hướng không thay đổi thói quen mã hóa của họ và không hoàn toàn có khả năng chấp nhận thử nghiệm đơn vị.

Nhiều người muốn bắt đầu với thử nghiệm tự động cố gắng giới thiệu chúng cho một cơ sở mã hiện có. Họ sẽ cố gắng viết các bài kiểm tra tích hợp kiểm tra rất nhiều chức năng của ứng dụng hiện có cùng một lúc. Các thử nghiệm tích hợp như vậy nổi tiếng là quá khó và quá tốn kém để duy trì. Lời khuyên: Giới thiệu các bài kiểm tra tự động cho một cơ sở mã mới.

Bài kiểm tra đơn vị là bài kiểm tra tốt để được tự động. Tất cả mọi thứ ở trên (kiểm tra tích hợp, kiểm tra thành phần, kiểm tra hệ thống) cũng có thể được kiểm tra tự động, nhưng tỷ lệ lợi ích chi phí nhanh chóng giảm xuống khi nhiều chức năng được kiểm tra cùng một lúc. Hiệu ứng tiêu cực này được khuếch đại, nếu bạn xây dựng các thử nghiệm như vậy trên chức năng được kiểm tra đơn vị kém. Lời khuyên: Giới thiệu các bài kiểm tra tự động ở cấp độ kiểm tra đơn vị và xây dựng các kiểm tra tích hợp tự động trên nền tảng vững chắc của các bài kiểm tra đơn vị .

Từ những điểm trên phần lớn sự thành công của kiểm thử tự động phụ thuộc vào hiệu quả của các bài kiểm tra đơn vị. Bạn có bài kiểm tra đơn vị hiệu quả nếu bạn cảm thấy hiệu quả với bài kiểm tra đơn vị. Khi mọi người bắt đầu với thử nghiệm đơn vị, họ có xu hướng cải thiện mã hiện tại và thói quen mã hóa thành các thử nghiệm đơn vị. Trớ trêu thay đây là cách khó nhất để học kiểm tra đơn vị. Ngoài ra kiểm tra đơn vị yêu cầu bạn thay đổi cách bạn viết mã (ví dụ: áp dụng các nguyên tắc RẮN ). Hầu hết các lập trình viên sớm dừng viết bài kiểm tra đơn vị vì họ nghĩ rằng đường cong quá dốc và cảm thấy khó xử khi bọc các bài kiểm tra đơn vị xung quanh một mã được thiết kế không kiểm tra được. Lời khuyên: Tìm hiểu thử nghiệm đơn vị từ cơ sở với mã mới và đối phó với thực tế là bạn cần thay đổi thói quen mã hóa của mình.

Có rất nhiều yếu tố khác, nhưng tôi thấy rằng đối với hầu hết các lập trình viên, thật khó khăn khi thay đổi cách viết mã. Mã được viết mà không có kiểm tra chỉ trông khác nhau. Nếu bạn không thể ép mã của mình vào một thiết kế có thể kiểm tra, rất có thể bạn sẽ không thể viết các bài kiểm tra đơn vị hiệu quả. Điều này phá hủy mặt đất để thử nghiệm tự động hiệu quả.

Tôi đã trải nghiệm điều đó một mình và bây giờ tôi rất vui khi được làm việc trong một công ty giới thiệu thành công các bài kiểm tra tự động. Tôi có thể viết nhiều hơn về các yếu tố khác, nhưng tôi nghĩ rằng thói quen mã hóa và kiểm tra đơn vị là những yếu tố quan trọng nhất. May mắn thay, có những người khác có nhiều kinh nghiệm hơn tôi và điền vào sách những bí quyết của họ. Một trong những cuốn sách này là Brownfield Application Development in .NET mà tôi thực sự có thể giới thiệu, vì bạn đang sử dụng kho công nghệ của Microsoft.

Một điều mà tôi chưa thấy rõ trong các câu trả lời ở trên là thử nghiệm đơn vị về cơ bản là hàng hóa công cộng và chi phí tư nhân. Tôi đã viết một bài blog về nó ở đây .

Điều quan trọng là trong khi một bộ các bài kiểm tra mang lại lợi ích cho nhóm hoặc một nhà phát triển cá nhân, thì việc viết bài kiểm tra là một chi phí cho người thực hiện nó, hầu hết thời gian.

Nói tóm lại, trừ khi viết bài kiểm tra được thi hành bằng cách nào đó - và các câu trả lời ở trên liệt kê một số cách khác nhau để làm điều đó - không có lý do gì để một nhà phát triển cá nhân thực hiện việc này.

Trong một công ty mà tôi đã làm việc, viết bài kiểm tra đơn vị là một phần bắt buộc để cung cấp một tính năng. Mã mới không được chấp nhận trừ khi thử nghiệm đơn vị là một phần của cam kết hoặc tính năng mới - có các đánh giá mã ngắn gọn cho mọi "nhiệm vụ" mà nhà phát triển được đưa ra. Có thể đáng để thực hiện một chính sách tương tự tại nơi làm việc của bạn.

Điều thú vị là doanh nghiệp thử nghiệm nhiều hơn các nhà phát triển! Đối với tôi có vẻ như thách thức lớn nhất của bạn là vượt qua sự kháng cự của các nhà phát triển để thay đổi; họ cần xác định lại sự hiểu biết về công việc của họ để bao gồm kiểm tra đơn vị.

Không có gì có thể giúp bạn nhiều hơn những thành công thử nghiệm đơn vị sớm để giúp các nhà phát triển của bạn vượt qua khả năng chống lại việc viết các bài kiểm tra này. Nếu bạn thúc đẩy họ làm một cái gì đó mới, hãy chắc chắn rằng bạn đẩy đầu tiên cho một thứ gì đó với phần thưởng gần như được đảm bảo.

@SkipHuffman đã chạm vào điều này, nhưng tôi sẽ nói thẳng ra. Một số thứ phù hợp hơn với thử nghiệm tự động hơn những thứ khác. Đối với lần đầu tiên, tôi sẽ KHÔNG kiểm tra cơ sở dữ liệu hoặc giao diện người dùng. Đầu vào từ cơ sở dữ liệu có thể cực kỳ khó thiết lập và phá bỏ. Các thử nghiệm đầu ra UI có xu hướng nhanh chóng bị phá vỡ bằng cách xem và cảm nhận những thay đổi hoàn toàn không liên quan đến các thử nghiệm của bạn.

Cái mà tôi gọi là "phần mềm trung gian" là hoàn hảo để thử nghiệm đơn vị. Mã đã xác định rõ điều kiện đầu vào và đầu ra. Nếu bạn tuân theo nguyên tắc DRY (Đừng lặp lại chính mình), bạn sẽ viết một số lớp hoặc hàm nhỏ để giải quyết các vấn đề định kỳ duy nhất cho ứng dụng của bạn.

Kiểm thử đơn vị là một công cụ tuyệt vời để hạn chế rủi ro thay đổi các thành phần nội bộ hiện có. Viết kiểm tra đơn vị trước khi thay đổi một thành phần nội bộ đã hoạt động trong một thời gian dài. Những thử nghiệm này chứng minh rằng chức năng hiện đang làm việc được bảo tồn. Khi bạn đã thực hiện thay đổi của mình và tất cả các bài kiểm tra đơn vị đều vượt qua, bạn biết rằng bạn chưa phá vỡ bất cứ điều gì "xuôi dòng". Nếu bạn tìm thấy một vấn đề hạ lưu, hãy thêm một bài kiểm tra đơn vị cho nó!

Ron Heifitz sẽ nói "giải quyết xung đột trong các giá trị mà mọi người nắm giữ hoặc để thu hẹp khoảng cách giữa các giá trị mà mọi người đại diện và thực tế mà họ phải đối mặt. Công việc thích ứng đòi hỏi phải thay đổi giá trị, niềm tin hoặc hành vi." Sau khi bạn vượt qua sự kháng cự của con người để thay đổi, bạn có thể phân nhánh vào các khu vực thử nghiệm khó khăn hơn khi thích hợp.

Một điều về kiểm thử tự động là nó yêu cầu bạn phải viết mã để có thể kiểm tra được. Bản thân đây không phải là một điều xấu (thực tế là nó tốt vì nó không khuyến khích nhiều thực tiễn mà theo quy tắc nên tránh), nhưng nếu bạn đang cố gắng áp dụng thử nghiệm đơn vị cho mã hiện tại thì có khả năng là không đã được viết một cách có thể kiểm chứng.

Những thứ như singletons, phương thức tĩnh, đăng ký, định vị dịch vụ, v.v ... giới thiệu các phụ thuộc rất khó để chế giễu. Vi phạm Luật Demeter có nghĩa là quá nhiều phần trong cơ sở mã của bạn biết quá nhiều về cách các phần khác của chức năng cơ sở mã của bạn, đưa ra các phụ thuộc ẩn khác có thể khó phá vỡ. Tất cả những điều này gây khó khăn cho việc cô lập một mô-đun khỏi phần còn lại của cơ sở mã và nếu bạn không thể kiểm tra các mô-đun của mình một cách riêng lẻ thì các kiểm tra đơn vị sẽ mất rất nhiều giá trị của chúng. Nếu thử nghiệm thất bại là do lỗi trong thiết bị được thử nghiệm hoặc do lỗi ở một trong các phụ thuộc của nó, hoặc có thể là do dữ liệu được kéo qua nguồn dữ liệu phụ thuộc không phải là điều mà người viết thử nghiệm mong đợi ? Nếu bạn có thể'

Hầu hết các cơ sở mã hóa mà tôi thấy rằng không được xây dựng với kiểm thử đơn vị có xu hướng không thể kiểm chứng được, vì các lập trình viên có xu hướng tập trung vào làm cho mã hoạt động như họ mong muốn thay vì thực hiện công việc cần thiết để giữ cho khớp nối lỏng lẻo và phụ thuộc rõ ràng . Mã được viết với thử nghiệm đơn vị trong tâm trí có xu hướng trông rất khác nhau.

Rất nhiều người áp dụng cách tiếp cận ngây thơ để thử nghiệm đơn vị khi họ bắt đầu thực hiện lần đầu tiên, họ nghĩ rằng họ chỉ có thể viết một loạt các thử nghiệm cho một cơ sở mã hiện tại và tất cả sẽ tốt, nhưng nó không bao giờ hoạt động theo cách đó vì các vấn đề nêu trên. Họ bắt đầu phát hiện ra rằng họ phải điều chỉnh số lượng thiết lập trong các bài kiểm tra đơn vị để khiến chúng chạy hoàn toàn, và kết quả thường bị nghi ngờ bởi vì thiếu mã tách biệt có nghĩa là bạn không thể theo dõi điều gì gây ra lỗi kiểm tra. Họ cũng có xu hướng bắt đầu thử viết các bài kiểm tra "thông minh" thể hiện một số khía cạnh trừu tượng cao về cách hệ thống nên hoạt động. Điều này có xu hướng thất bại bởi vì một bài kiểm tra đơn vị "thông minh" là một nguồn tiềm năng của lỗi. Đã thử nghiệm thất bại vì một lỗi trong mô-đun thử nghiệm, hoặc vì một lỗi trong bài kiểm tra? Một bài kiểm tra rất đơn giản đến nỗi rõ ràng không có khả năng một lỗi có thể ẩn trong đó. Trong thực tế, các bài kiểm tra tốt nhất hiếm khi dài hơn 2 dòng, dòng đầu tiên hướng dẫn đơn vị được kiểm tra thực hiện điều gì đó, lần thứ hai khẳng định rằng những gì nó đã làm là những gì được mong đợi.

Nếu nhóm của bạn nghiêm túc về việc áp dụng thử nghiệm đơn vị thì sẽ không khôn ngoan khi bắt đầu với một dự án hiện có. Các dự án hiện tại của nhóm bạn có thể không thể thực hiện được nếu không tái cấu trúc lớn. Tốt hơn hết là bạn nên sử dụng một dự án mới làm cơ sở để tìm hiểu về kiểm thử đơn vị, vì bạn có một bảng xếp hạng rõ ràng để làm việc. Bạn có thể thiết kế cơ sở mã mới để ưu tiên tiêm phụ thuộc vào singletons, đăng ký và các phụ thuộc ẩn khác, bạn có thể viết nó để phụ thuộc vào giao diện thay vì triển khai, v.v. Bạn cũng có thể (và nên) viết các bài kiểm tra bên cạnh mã đang được kiểm tra, vì việc viết các bài kiểm tra sau đó dẫn đến các bài kiểm tra đơn vị để đảm bảo mô-đun được kiểm tra thực hiện những gì bạn nghĩ nó có thể làm thay vì kiểm tra mà nó thực hiện. những gì các thông số kỹ thuật nói nó nên làm.

Khi bạn đã có được sự tự tin với thử nghiệm đơn vị, nhóm của bạn có thể sẽ bắt đầu nhận ra các lỗ hổng trong mã hiện tại của họ sẽ là trở ngại cho các thử nghiệm đơn vị. Đây là khi bạn có thể bắt đầu làm việc để cấu trúc lại mã hiện có để làm cho nó dễ kiểm tra hơn. Đừng tham vọng và cố gắng làm tất cả điều này cùng một lúc, hoặc cố gắng thay thế một hệ thống hoạt động với một hệ thống hoàn toàn mới, chỉ cần bắt đầu bằng cách tìm các bit của cơ sở mã có thể dễ dàng kiểm tra (những hệ thống không có bất kỳ phụ thuộc hoặc nơi phụ thuộc là rõ ràng) và viết bài kiểm tra cho những người phụ thuộc. Tôi biết tôi đã nói viết một bài kiểm tra bên cạnh mã tốt hơn là viết các bài kiểm tra sau đó, nhưng ngay cả một bài kiểm tra được viết sau đó vẫn có giá trị như một điểm khởi đầu. Viết các bài kiểm tra như thể bạn không biết gì về cách lớp hoạt động ngoài những thông số kỹ thuật của nó nói nó nên làm. Khi bạn chạy thử nghiệm và gặp thất bại, thì thông số kỹ thuật hoặc việc thực hiện là sai. Kiểm tra kỹ cả hai để xác định cái nào sai và cập nhật kiểm tra hoặc mã cho phù hợp.

Khi bạn đã chọn trái cây treo thấp, công việc thực sự của bạn bắt đầu. Bạn cần bắt đầu tìm các phụ thuộc ẩn trong cơ sở mã của mình và sửa chúng từng cái một. Tại thời điểm này, đừng quá tham vọng, chỉ cần thực hiện một mô-đun tại một thời điểm hoặc thậm chí chỉ một vấn đề duy nhất trong một mô-đun, cho đến khi các trở ngại để kiểm tra được khắc phục và bạn có thể chuyển sang bit tiếp theo.

TL: DR: Hầu hết mọi người nghĩ rằng kiểm tra là dễ dàng và bạn có thể cải thiện các kiểm tra thành mã hiện có một cách dễ dàng. Cả hai giả định này đều sai. Nếu bạn bắt tay vào một dự án để đưa thử nghiệm đơn vị vào các dự án của bạn với cả hai sự thật này, bạn sẽ có nhiều khả năng thành công hơn.

• Có ai ở công ty bạn có nhiều kinh nghiệm làm kiểm tra tự động không?

Nếu không, các sáng kiến ​​thử nghiệm tự động có thể sẽ thất bại. Kiểm thử tự động là một kỹ năng, giống như nhiều kỹ năng khác trong lập trình, và nếu bạn không có ai có kinh nghiệm làm việc đó, thì không dễ để biết thử nghiệm tự động là thử nghiệm tự động tốt có giá trị thực hay là thử nghiệm xấu thất bại ngẫu nhiên / yêu cầu cập nhật thường xuyên / không thực sự thực hiện bất kỳ mã thú vị nào.

• Có ai đó có quyền lực lãnh đạo? Họ có thể yêu cầu thay đổi?

Nếu không ai lắng nghe, sẽ không có vấn đề gì nếu họ nói rằng bài kiểm tra là không tốt. (Lưu ý rằng quyền lực lãnh đạo không cần phải được chính thức hóa. Có một đội ngũ quan tâm cũng tốt.)

• Bạn có đang phát triển các công cụ và quy trình để làm cho thử nghiệm tự động dễ dàng thực hiện và tích hợp hơn vào chu trình phát triển không?

Các nhà phát triển lười biếng. Bạn cần làm cho những điều bạn muốn chúng thực hiện dễ dàng và những điều bạn không muốn chúng khó thực hiện hơn. Bạn nên đảm bảo các thư viện kiểm thử giúp dễ dàng thực hiện các tác vụ liên quan đến thiết lập và phân tích kiểm tra, đặc biệt là thiết lập liên quan đến môi trường, như cơ sở dữ liệu kiểm tra hoặc tương tự. . một người truy cập dữ liệu cá nhân.)

Bạn cũng nên đảm bảo rằng các IDE của bạn có một cách tốt để khởi chạy bộ thử nghiệm. Bạn nên chạy bộ kiểm tra thường xuyên để mọi người chú ý khi nó thất bại thay vì để nó nán lại trong đau khổ. Các nhà phát triển cũng phản hồi tốt với phản hồi, ví dụ: một hệ thống tích hợp tự động hoàn nguyên các thay đổi của họ nếu họ đã phá vỡ một bài kiểm tra. Hoặc, tốt hơn, phản hồi tích cực: một hệ thống tích hợp tự động bắt lỗi và cứu bạn khỏi phá vỡ mọi thứ.

Đầu tiên, nếu nhà phát triển của bạn không thấy giá trị của các thử nghiệm của bạn, thì có lẽ vì các thử nghiệm của bạn không có giá trị, không phải vì các nhà phát triển của bạn mù quáng với giá trị của họ hoặc nói chung về giá trị của các thử nghiệm. Trong số các nhà truyền giáo của nó, có một xu hướng tin rằng sự phát triển dựa trên thử nghiệm không thể thất bại, nó chỉ có thể bị thất bại bởi những nhà phát triển lười biếng, lười biếng. Tôi nghĩ rằng điều này là sai và phản tác dụng.

Khi tôi được giới thiệu để phát triển theo hướng kiểm tra, điều đó có nghĩa là, viết một bài kiểm tra để xác minh rằng một phương pháp sẽ không bao giờ thất bại không bao giờ thất bại. Điều đó là tốt, lúc đầu, bởi vì bạn nhận được một kiểm tra màu xanh lá cây đáng yêu và cảm giác hoàn thành. Sau đó, sau khi bạn cấu trúc lại mã, bạn có hàng chục chữ X màu đỏ gây khó chịu, không ai trong số đó nói gì hơn mã đã thay đổi, rằng các bài kiểm tra không còn hiệu lực và bạn đã lãng phí rất nhiều thời gian để viết chúng.

Bạn muốn tránh điều đó.

Kể từ đó, tôi đã thực hiện một cách tiếp cận khác để kiểm tra. Thay vì một cặp thực hiện giao diện , tôi có một giao diện, thực hiện, kiểm tra ba . Giao diện chỉ định hành vi, việc thực hiện thực hiện hành vi, kiểm tra kiểm tra hành vi.

Tôi cho rằng nó có vẻ hiển nhiên, nhưng với tôi, nó phân biệt giữa mã bạn phải chứng minh hoạt động theo quy định và mã bạn có thể kiểm tra nhiều hay ít khi bạn thấy phù hợp. Mã bạn phải chứng minh là giao diện bạn cung cấp cho bên ngoài; phần còn lại là mối quan tâm của bạn một mình.

Trong trường hợp này, tôi sẽ hỏi các nhà phát triển xem họ có thấy sự phân chia tự nhiên trong mã trong đó loại thử nghiệm này sẽ phù hợp không. Có giao diện nào mà Đội A thực hiện và Đội B sử dụng không? Trong trường hợp đó, lợi ích của Đội B là đảm bảo rằng giao diện hoạt động như họ mong đợi. Yêu cầu Đội B viết một bài kiểm tra cho nó, sau đó báo cho Đội A để đảm bảo rằng việc thực hiện của họ phù hợp với bài kiểm tra; hoặc, nếu không, và nó cố tình không, để thảo luận về sự thay đổi bất ngờ với nhóm khác, để họ có thể chuẩn bị cho nó.

Tôi nghĩ rằng điều này sẽ minh họa giá trị của bài kiểm tra. Bản thân nó không phải là kết thúc, dù là những tấm séc xanh đáng yêu. Nó tồn tại để thực hiện rõ ràng lời hứa của nhà phát triển này với nhà phát triển khác và để đảm bảo rằng lời hứa được giữ cho sự hài lòng của cả hai.

Thêm nhiều bài kiểm tra đơn vị vào một dự án lớn có sẵn là một công việc khó khăn. Nếu bạn đã tìm thấy một khung mô phỏng tốt phù hợp với bạn thì bạn nên giải quyết vấn đề khó khăn nhất.

Tôi khuyên bạn nên thử thêm các bài kiểm tra khi bạn thêm các tính năng / sửa lỗi. Sửa lỗi là cách dễ nhất. Viết một bài kiểm tra không thành công do lỗi của bạn và sau đó sửa lỗi. Đồng thời có lẽ bạn sẽ thấy mình viết một số bài kiểm tra đơn giản hơn. Tất nhiên bạn thực sự muốn sử dụng một đoạn mã nhỏ và dễ dàng kiểm tra cho việc này.

Khi mọi người bắt đầu quen với việc viết bài kiểm tra cho những điều dễ dàng hơn, bạn hy vọng sẽ thấy họ viết mã của mình để dễ kiểm tra hơn.

Tôi cũng khuyên bạn nên đo mức độ bao phủ mã của các thử nghiệm của mình (trước đây tôi đã sử dụng cobertura cho Java). Bạn sẽ muốn có một số máy chủ tích hợp liên tục chạy các bài kiểm tra và tạo ra các số liệu một cách thường xuyên (mỗi ngày, mỗi lần đăng ký). Nếu các nhà phát triển đồng nghiệp của bạn quan tâm thì họ sẽ muốn thấy phạm vi bảo hiểm tăng theo thời gian và họ có thể thấy các lỗ hổng bảo hiểm trong một số

Tôi nghĩ rằng bạn có thể phải chơi trò chơi dài. Một điều bạn có thể làm để có được sự chấp nhận là cố gắng kiểm tra toàn bộ đơn vị tính năng tiếp theo bạn viết và sau đó theo dõi số lượng lỗi theo thời gian. Bạn hy vọng sẽ thấy rằng các lỗi lớn sẽ được phát hiện sớm (đặc biệt nếu bạn kết hợp điều này với Thiết kế hướng thử nghiệm) và số lượng hồi quy sẽ rất thấp. Sau một khoảng thời gian, giả sử 1 năm, so sánh các số liệu thống kê với các tính năng không được kiểm tra đơn vị có độ phức tạp tương tự. Nếu bạn có thể chỉ ra rằng số lượng lỗi và hồi quy mới thấp hơn đáng kể thì bạn đã cung cấp một lời biện minh tài chính cho nó và việc nhóm sản phẩm trở nên khó bỏ qua hơn.

Tôi đã có một tình huống mà tôi có thể sử dụng TDD và thử nghiệm đơn vị cho một tính năng chính. Sau khi kết thúc giai đoạn phát triển, không có một lỗi nào được báo cáo trong hơn 5 năm. Khi một cải tiến mới - và rủi ro - được yêu cầu, tôi đã có thể thực hiện nó và nắm bắt tất cả các hồi quy trong các bài kiểm tra đơn vị.

Theo ý kiến ​​mạnh mẽ của tôi, giá trị của các bài kiểm tra đơn vị phần lớn bị nhiều đội đánh giá thấp vì một số yếu tố, nhiều yếu tố đã được nêu bật trong các câu trả lời.

Thông thường các nhà phát triển chịu áp lực phải "hoàn thành công việc", vì vậy việc chứng minh rằng một khối mã hoạt động là một bằng chứng đầy đủ cho khách hàng. Điều này hầu như luôn áp dụng cho công ty tư vấn và QA do con người điều khiển: nếu khách hàng không yêu cầu thử nghiệm đơn vị và tạo ra bản demo trực tiếp đủ thì khách hàng đã hoàn toàn thất bại vì anh ta sẽ ký phê duyệt mã có thể che giấu lỗi.

Các nhà phát triển thường thất vọng. Trở thành một lập trình viên là một công việc khó khăn: hoàn thành một nhiệm vụ và đi tiếp theo là thỏa mãn, vì vậy mọi người đều muốn nhanh chóng và hoàn thành. Cho đến khi họ bị tấn công bởi một chiếc xe buýt với một lỗi lớn tăng lên hàng tháng sau QA ban đầu. Trong kịch bản này, QA tự động và liên tục là vấn đề của quản lý thay vì nhà phát triển (họ vẫn sẽ được trả tiền cho công việc của mình, có lẽ là làm thêm giờ).

Nhưng có một ngoại lệ

Tôi tin tưởng mạnh mẽ rằng việc chấp nhận mô hình thử nghiệm tự động là một chức năng của "tính nhân đạo" của các thử nghiệm đang được thực hiện. Nếu bạn đang thử nghiệm một mô-đun web với giao diện người dùng, nhiều khả năng, mặc dù các công cụ như Selenium, để tự điền vào biểu mẫu, hãy xem kết quả và tin vào tính xác định. Bạn sẽ quên chạy lại các bài kiểm tra sau hoặc bạn sẽ quá lười biếng để làm lại các bài kiểm tra cũ và đây là lý do tại sao các lỗi đôi khi được phát hiện sau đó. Để thúc đẩy điều này, việc mô đun hóa mã mạnh mẽ và các quy tắc nghiêm ngặt về "sửa đổi mã cũ" đã được chứng minh là chấp nhận được trong môi trường ngân hàng (theo kinh nghiệm làm việc cá nhân của tôi).

Thay vào đó, nếu nhà phát triển chịu trách nhiệm phát triển mô-đun dữ liệu tự động cao và khối lượng lớn, anh ta sẽ có khả năng viết các bài kiểm tra đơn vị kỹ lưỡng và gửi chúng cho các đợt kiểm tra. Điều này bởi vì việc lấp đầy một tải trọng XML lớn với dữ liệu được chuyển đổi từ nguồn dữ liệu ngoài (bị giả định hay không) không phải là một công việc dễ bị con người. Một số nhà phát triển thử nghiệm cuối cùng sẽ xây dựng một mặt trước nhỏ bé và hài hước cho loại thử nghiệm cụ thể này. Khi tôi làm việc tại luận án thạc sĩ, tôi đang làm việc trên một chiếc xe buýt ghi nhật ký xử lý hơn 6000 tin nhắn nhật ký hệ thống mỗi giây và tôi phải đo lường sự mất mát và hỏng gói: Tôi tự nhiên viết đơn vị và kiểm tra căng thẳng cho hầu hết tất cả các thành phần, đặc biệt là trình phân tích cú pháp Syslog.

Để làm cho các nhà phát triển dễ kiểm tra đơn vị hơn

Tôi tin rằng họ phải bị buộc phải. Nếu bạn là một khách hàng thông minh, bạn sẽ yêu cầu các chuyên gia tư vấn của bạn chạy bộ thử nghiệm đầy đủ ở mỗi QA. Nếu bạn là một người lãnh đạo nhóm tốt, bạn có thể nghĩ sẽ giao nhiệm vụ sau cho một nhà phát triển thông minh: xây dựng một nền tảng thử nghiệm bên trong. Điều đó không có gì để thấy với phản ứng nền tảng hiệu ứng bên trong, mà thay vào đó là một tập hợp các lớp trình trợ giúp, mô phỏng cơ sở dữ liệu, cấu hình, trình phân tích cú pháp, trình chuyển đổi, dao quân đội Thụy Sĩ để giúp các nhà phát triển xây dựng các bài kiểm tra nhanh chóng.

Các nền tảng thử nghiệm hiện tại như NUnit là mục đích chung và cho phép bạn xác minh các xác nhận chung. Sử dụng chính xác việc tiêm phụ thuộc và các nhà máy dành riêng cho dự án giúp các nhà phát triển viết ít mã hơn cho các thử nghiệm và hạnh phúc hơn. Tôi chưa có cơ hội thử nghiệm điều này trên một dự án đầy đủ, tôi không thể cung cấp phản hồi thực tế.

Kiểm thử tự động giống như phát triển phần mềm. Thật không may, những người bạn thuê để thử nghiệm ban đầu dự định viết các trường hợp thử nghiệm, kế hoạch, chiến lược, theo dõi quá trình xem xét, kiểm tra thủ công và ghi nhật ký lỗi.

Ngay khi chúng được giao trách nhiệm kiểm tra tự động, nó bao gồm một số lượng phát triển phần mềm. Điều hấp dẫn ở đây là, việc kiểm tra tự động, bất kể bạn sử dụng công cụ nào (và vì lợi ích của thiên đường không tranh luận về điểm này), cần được bảo trì và cập nhật hàng ngày. Khi các nhà phát triển thay đổi mã,

• bạn cần đảm bảo rằng các bài kiểm tra được tiếp tục chạy.
• Bạn cần đảm bảo rằng các bài kiểm tra không bị xóa vì chúng không chạy
• số liệu kiểm tra của bạn cần hiển thị những gì bạn đã chạy trên bản dựng cuối cùng và bản dựng này. Để đảm bảo rằng # trường hợp thử nghiệm của bạn không giảm.
• các trường hợp thử nghiệm cần được xem xét giống như phát triển để đảm bảo rằng mọi người không bị rối, hãy chia 1 thử nghiệm thành 2 chỉ để tăng số lượng (một số lần thử nghiệm được thuê ngoài, vì vậy việc theo dõi này rất quan trọng)
• giao tiếp "lành mạnh" hơn nhiều giữa dev và test rất quan trọng
• giữ non-functionalcác bài kiểm tra riêng biệt và đừng mong đợi chúng chạy nó hàng ngày, cần có thời gian để duy trì những bài kiểm tra này và tốt. Nhưng đừng bỏ cuộc, hãy đảm bảo rằng chúng được duy trì.

Bạn thất bại vì những lý do này

• kỹ sư kiểm tra của bạn là kỹ sư kiểm tra thủ công không có kỹ năng phân tích. họ không biết sự khác biệt giữa a ifvà whilevòng lặp. Bởi vì thật lòng không có khóa học nào dạy kiểm tra tự động, họ chỉ dạy kiểm tra thủ công.
• các kỹ sư kiểm tra của bạn quá bận rộn kiểm tra thủ công các bản dựng của bạn và ghi nhật ký lỗi để họ mất theo dõi các kiểm tra tự động
• người quản lý kiểm tra của bạn không quan tâm đến số liệu từ các kiểm tra tự động, chỉ vì chúng hiển thị dữ liệu không hợp lệ (khi dự án bắt đầu) và họ không đặt nỗ lực hoặc ưu tiên trong các cuộc họp và cuộc họp hàng ngày để nhấn mạnh tầm quan trọng của việc tự động hóa và chạy
• bạn chọn tự động hóa các bài kiểm tra cho các ứng dụng di động, có thời hạn sử dụng rất ngắn. tại thời điểm bạn viết, hãy ổn định bộ kiểm tra tự động thay đổi yêu cầu ứng dụng của bạn, thay vào đó bạn nên tập trung vào kiểm tra dịch vụ web chạy ứng dụng của mình
• bạn không hiểu rằng nhóm kiểm tra tự động tuân theo cùng một cột mốc là nhóm phát triển, tính năng hoàn tất, mã hoàn thành, khóa mã và đóng băng mã.
• bạn không phân biệt giữa người kiểm tra thủ công và người kiểm tra tự động.
• cả hai đều được trả cùng mức lương và báo cáo cho cùng một người quản lý, lý tưởng nhất là họ nên báo cáo cho người quản lý nhà phát triển và mức lương của họ phải phù hợp với những người phát triển.
• bạn thực sự nghĩ và tin rằng Junit là không đủ để phát triển các bài kiểm tra tự động :).

Đây là từ kinh nghiệm của tôi khi làm việc cho các công ty thực hiện kiểm thử tự động rất nghiêm túc và hiểu rằng dev rất quan trọng như các kỹ sư kiểm thử tự động. Và từ kinh nghiệm của tôi làm việc cho những người không biết, hiểu sự khác biệt, bất kể bạn giải thích với họ nhiều như thế nào.