Làm cách nào để thử nghiệm không nhàm chán?

Question

Giống như tiêu đề đã nói. Những cách nào bạn sử dụng để kiểm tra mã của riêng bạn để nó sẽ không phải là một nhiệm vụ nhàm chán? Bạn có sử dụng bất kỳ công cụ nào không? Đối với các dự án của tôi, tôi sử dụng bảng tính để liệt kê tất cả các thói quen có thể có được từ CRUD cơ bản và tất cả các thói quen kỳ lạ. tôi thực hiện khoảng 10 thói quen.

Tôi nhận được khoảng 2-3 lỗi và đôi khi những lỗi chính bằng cách thực hiện việc này. Và nếu tôi không làm điều này, khách hàng sẽ báo cáo lỗi khác.

Vì vậy, hãy cho tôi biết bạn sử dụng kỹ thuật nào trong việc thử nghiệm mã của riêng bạn theo cách mà nó không mang bạn đến?

Edit:

tôi quên đề cập đến mà tôi đang đặc biệt là làm việc trên các ứng dụng dựa trên web và ngôn ngữ của tôi là khuôn khổ PHP & CakePHP.

Answer 1

Có các thử nghiệm nhanh.Phản hồi tức thì (thêm) giúp tạo ra các lần lặp ngắn. Điều này gần như có thể khiến bạn nghiện bắt đầu chạy thử nghiệm tiếp theo.

Answer 2

Để có mã mới, hãy tìm hiểu xem mã nên làm gì, viết một bài kiểm tra xác nhận rằng mã đó thực hiện, tìm hiểu cách thực hiện, sau đó viết mã.

Để tìm lỗi trong mã hiện có, kiểm tra tái tạo lỗi giúp dễ dàng kiểm tra hơn.

Điều này không nhàm chán, vì trong cả hai trường hợp, các thử nghiệm có khả năng thất bại cao.

Đối với UAT, sau đó tôi đã không tìm thấy bất kỳ cách nào không nhàm chán - bạn đi qua các yêu cầu từng người một và thực hiện càng nhiều bài kiểm tra được yêu cầu cho chức năng. Lý tưởng nhất cho các dự án mới, mà hầu như đã được thực hiện ở phía trước như là một phần của việc xây dựng, nhưng không phải lúc nào cũng vậy. Chỉ khi bạn viết bài kiểm tra sau khi thực tế là bạn phải có một danh sách dài các bài kiểm tra mà bạn đã biết sẽ vượt qua thì nó sẽ trở nên nhàm chán.

Answer 3

Tôi không thấy làm thế nào nó có thể nhàm chán vì nó là một phần lớn của bản thân chương trình. Tìm và loại bỏ lỗi là rất quan trọng, nhưng nếu bạn nghĩ rằng nó nhàm chán có thể bạn muốn viết mã trong trường hợp bạn có thể viết một vài dòng kiểm tra các bộ phận quan trọng trong mã của bạn.

Answer 4

Tôi cố gắng viết Bài kiểm tra trước và cố gắng thiết kế lớp học xung quanh. Vì vậy, tôi thực sự thử nghiệm tập trung. Tôi đang sử dụng JUnit, v.v.

Nếu bạn thử Lập trình theo cách đó..kiểm tra ngày càng trở nên thú vị hơn, theo quan điểm của tôi.

Answer 5

Một trong những lời khuyên tôi cung cấp cho nhóm của mình là liên quan đến một tính năng mới 90% logic nên chạy ra ngoài ngữ cảnh của ứng dụng.

Các tính năng có thể chạy bên ngoài ngữ cảnh ứng dụng luôn dễ dàng kiểm tra.

Nếu bạn đang sử dụng .net, bạn có thể điều tra NUnit.

Bạn cũng có thể xem Pex. Nó có vẻ là một khuôn khổ thử nghiệm tuyệt vời.

Tuy nhiên, câu hỏi của bạn hơi chung chung vì có nhiều loại thử nghiệm.

Hãy thử nghiệm thú vị :).

Answer 6

Bạn có thể có nghĩa là tẻ nhạt, thay vì nhàm chán. Nếu vậy, this article có thể giúp

Answer 7

"Không thử nghiệm, không nhàm chán".

Answer 8

Nếu bạn thấy thử nghiệm nhàm chán điều này là bởi vì kiểm tra mã của bạn là một điều ác cần thiết ... ít nhất là cách tôi cảm nhận bạn thấy nó.

Tất cả những gì bạn cần ở đây là thay đổi quan điểm của bạn đối với thử nghiệm ... và cụ thể hơn ... thay đổi về cách bạn đang thử nghiệm. Bạn thích lập trình nhiều hơn kiểm tra ... cũng lập trình các bài kiểm tra của bạn ... sau đó nó chỉ là thú vị như lập trình điều bắt đầu với ... và khi bạn đã hoàn thành, bạn có

1. một chương trình mà làm việc

2. một bộ kiểm tra những gì còn lại và kiểm tra nó mỗi xây dựng

do đó, hãy trội tờ và từng bước gỡ rối và tham gia những niềm vui :-)

trong số Tất nhiên có nhiều điều hơn nữa và điều này nơi mà các khuôn khổ kiểm tra (junit, testNG, Dunit, NUnit ...) sẽ có ích, chúng sẽ mất đi một chút và chỉ để lại phần mã hóa của bài kiểm tra ..

Chúc mừng mã hóa và mở rộng .. thử nghiệm hạnh phúc :-)

---

rất ít tài liệu tham khảo bạn có thể thấy hữu ích, tôi không phải là một chuyên gia về PHP, xa nó nhưng nó dường như để phù hợp với mục đích này.

• http://www.simpletest.org/
• http://www.phpunit.de/
• http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/

Answer 9

Tôi đã từng nghĩ giống như bạn. Khi tôi lần đầu tiên bắt đầu lập trình, chúng tôi đã phải tìm ra đầu ra trên giấy và sau đó so sánh trực quan với đầu ra thực tế và dự kiến. Nói về tẻ nhạt. Một vài năm trước, tôi phát hiện ra Test Driven Development và xUnit và bây giờ tôi thích các bài kiểm tra.

Về cơ bản, trong TDD, bạn có một khung được thiết kế để cho phép bạn viết các kiểm tra và chạy chúng rất dễ dàng. Vì vậy, viết các bài kiểm tra chỉ trở thành viết mã. Quá trình này là:

1. Chỉ cần viết đủ để cho phép bạn viết bài kiểm tra. Ví dụ: bạn đang thêm một phương thức vào một lớp, vì vậy bạn chỉ cần viết phương thức sig và bất kỳ câu lệnh trả về nào cần thiết để có được nó để biên dịch.
2. Sau đó, bạn viết thử nghiệm đầu tiên và chạy khung để thấy rằng nó không thành công.
3. Sau đó, bạn thêm mã vào/refactor phương pháp của bạn để vượt qua bài kiểm tra.
4. Sau đó, bạn thêm thử nghiệm tiếp theo và thấy rằng nó không thành công.
5. Lặp lại 3 và 4 cho đến khi bạn không thể nghĩ ra bất kỳ thử nghiệm nào khác.
6. Bạn đã hoàn tất.

Đó là một trong những điều tốt đẹp về TDD: khi mã của bạn vượt qua mọi thử nghiệm bạn có thể nghĩ, bạn biết bạn đã hoàn thành - không có TDD, đôi khi rất khó để biết khi nào nên dừng. Các bài kiểm tra của bạn đến từ đâu? Họ đến từ spec. TDD thường giúp bạn nhận ra rằng thông số kỹ thuật. có đầy đủ các lỗ khi bạn nghĩ về các trường hợp thử nghiệm cho những thứ không có trong spec. Bạn có thể nhận được những câu hỏi này được trả lời trước khi bắt đầu viết mã để xử lý chúng. Một điều thú vị nữa là khi bạn phát hiện ra lỗi sau, bạn có thể bắt đầu làm lại mã của bạn an toàn trong kiến ​​thức rằng tất cả các bài kiểm tra hiện tại sẽ chứng minh mã của bạn vẫn hoạt động cho tất cả các trường hợp đã biết, trong khi các bài kiểm tra mới bạn ' đã viết để tạo lại lỗi sẽ hiển thị cho bạn khi bạn đã sửa nó.

Bạn có thể thêm kiểm tra đơn vị vào mã hiện có - chỉ cần thêm chúng cho các bit bạn đang thay đổi. Khi bạn tiếp tục quay trở lại với nó, các bài kiểm tra sẽ nhận được nhiều hơn và nhiều hơn nữa bảo hiểm.

xUnit là tên chung cho một loạt các khung công tác hỗ trợ các ngôn ngữ khác nhau: JUnit cho Java, NUnit cho .NET, v.v. Có thể đã là một ngôn ngữ cho bất kỳ ngôn ngữ nào bạn sử dụng. Bạn thậm chí có thể write your own framework. Đọc cuốn sách này - thật tuyệt vời.

Answer 10

Tôi làm việc cho một công ty nhỏ nhưng chúng tôi có một nhóm thử nghiệm riêng biệt. Điều này là do các nhà phát triển thường bị mù vì lỗi riêng của họ, do đó họ có xu hướng trở thành người thử nghiệm xấu. Nhóm thử nghiệm của chúng tôi gồm các kỹ sư kiểm tra có kinh nghiệm làm việc theo các kế hoạch kiểm tra được xác định trước và thường sử dụng các công cụ kiểm tra tự động để kiểm tra các ứng dụng mà chúng tôi tạo ra. (Bao gồm các trang web!) Họ là không phải là nhà phát triển! Những người thử nghiệm này sử dụng TMap để thử nghiệm tự động. Phần còn lại chỉ là lao động thủ công, đọc các thiết kế chức năng và đảm bảo rằng mọi thứ được đề cập trong thiết kế chức năng sẽ hoạt động chính xác chính xác như như được mô tả trong phiên bản cuối cùng. Bất kỳ lỗi nào được báo cáo lại cho nhà phát triển bằng cách sử dụng công cụ báo cáo lỗi nội bộ.

Answer 11

Viết tự động kiểm tra đơn vị, với PhpUnit hoặc Simpletest vì bạn đang sử dụng PHP hoặc bất kỳ ngôn ngữ nào khác mà bạn chọn. Theo sau Test-Driven Development (TDD), bạn sẽ xây dựng một bộ thử nghiệm cùng với mã của bạn. Bạn sẽ không có ấn tượng bạn đang thử nghiệm bất cứ điều gì. Có thật không.

"* kiểm tra một chút, viết mã một chút *".

Answer 12

Viết một số kiểm tra đơn vị/kiểm tra tự động, sẽ tự động chạy, ví dụ: sau khi một xây dựng mới đã được thực hiện.

Sử dụng gói gọn và chỉ thử kiểm tra dựa trên giao diện.

Viết một số công cụ nhỏ để giúp bạn kiểm tra các mô-đun/lớp học của mình.

Answer 13

Làm cho việc sử dụng dễ dàng, bộ thử nghiệm rất dễ thực hiện đối với các chương trình Perl. Có một cách tiêu chuẩn để thực hiện kiểm tra trong Perl bằng cách sử dụng Test Anything Protocol.

Về cơ bản, bạn viết một loạt tệp có đuôi mở rộng .t, trong thư mục t/ của dự án và sau đó chạy prove.

Các tập tin trong t/ về cơ bản giống như thế này:

#!/usr/bin/perl 
use strict; 
use warnings; 

use Test::More tests => 8; 

use Date::ICal; 

$ical = Date::ICal->new(year => 1964, month => 10, day => 16, 
         hour => 16, min => 12, sec => 47, 
         tz => '0530'); 

ok(defined $ical,   'new() returned something'); 
ok($ical->isa('Date::ICal'), " and it's the right class"); 
is($ical->sec,  47,  ' sec()' ); 
is($ical->min,  12,  ' min()' );  
is($ical->hour, 16,  ' hour()' ); 
is($ical->day,  17,  ' day()' ); 
is($ical->month, 10,  ' month()'); 
is($ical->year, 1964,  ' year()' ); 

Để biết thêm thông tin bạn có thể đọc tutorial.

Có nhiều ngôn ngữ có mô-đun được thiết kế để hoạt động với The TAP, có giao diện here để biết thêm thông tin.

Thật không may, TAP chỉ mới được sử dụng cho các ngôn ngữ khác so với Perl, vì vậy không có nhiều hỗ trợ cho chúng, vì có tồn tại cho Perl.

Answer 14

Trước tiên hãy sử dụng kiểm tra lập trình thử nghiệm đầu tiên \ pair.

Nếu bạn viết chúng sau khi bạn đã viết mã của riêng bạn, thì mục tiêu của bạn là tìm sai lầm trong công việc = mục tiêu buồn.

Ngược lại, nếu bạn viết bài kiểm tra trước khi viết mã, thì mục tiêu của bạn là viết phần mềm hoàn hảo = mục tiêu hạnh phúc.

Answer 15

Không viết các bài kiểm tra cho những thứ tầm thường - ít nhất là không cho đến khi nó bị phá vỡ, tức là trong những dịp hiếm hoi. Nếu bạn làm thế thì bạn sẽ cảm thấy khó chịu mỗi khi bạn cần đến và duy trì những bài kiểm tra đó. Đó là hoàn toàn bình thường, chán nản lười biếng lười biếng vv là phản ứng bản năng tự nhiên của bạn để làm việc vô nghĩa.

Hoàn toàn ngược lại, viết các bài kiểm tra cho các thuật toán không tầm thường & logic, khám phá các trường hợp góc mà bạn thậm chí không nghĩ đến là trải nghiệm thú vị và rất bổ ích.