Ai phát triển dựa trên thử nghiệm?

Tôi đã làm việc trong không gian doanh nghiệp trong 4 năm rưỡi qua và nhận thấy rằng nói chung, các doanh nghiệp không phải là môi trường thuận lợi cho phong cách phát triển thử nghiệm đầu tiên. Các dự án thường có chi phí cố định, dòng thời gian cố định và kiểu thác nước. Bất kỳ thử nghiệm đơn vị nào, nếu được thực hiện, thường đến sau khi phát triển trong giai đoạn QA và được thực hiện bởi một nhóm khác.

Trước khi làm việc cho một doanh nghiệp, tôi đã tham khảo ý kiến ​​cho nhiều công ty vừa và nhỏ, và không ai trong số họ sẵn sàng trả tiền cho một dự án phát triển theo phong cách thử nghiệm đầu tiên. Họ thường muốn phát triển bắt đầu ngay lập tức hoặc sau một thời gian thiết kế ngắn: tức là, một cái gì đó gần giống với Agile, mặc dù một số khách hàng muốn mọi thứ được vạch ra tương tự như thác nước.

Với những loại cửa hàng, công ty và khách hàng nào phát triển dựa trên thử nghiệm hoạt động tốt nhất? Những loại dự án có xu hướng có lợi cho TDD?

Mỗi dòng mã tôi viết đều sử dụng phát triển theo hướng kiểm tra. Nếu ban quản lý không tham gia viết bài kiểm tra trước thì tôi sẽ không nói với ban quản lý về việc đó. Tôi cảm thấy mạnh mẽ rằng phát triển theo hướng kiểm tra là một quá trình tốt hơn.

Ông chủ của tôi đã cho tôi ăn một món ngon ngày hôm nay, tôi nghĩ rằng tôi sẽ ăn cắp nó giống như anh ta đã ăn cắp nó từ người khác.

"Bạn có mong đợi một thợ mộc để đo bảng trước khi anh ta cắt nó?"

Tôi học lớp cửa hàng gỗ ở trường trung học và làm việc xây dựng thông qua trường học. Câu thần chú của chúng tôi luôn là "đo hai lần, cắt một lần", sau đó là câu châm biếm "Tôi cắt nó và cắt lại và nó vẫn còn quá ngắn!"

Nếu bạn kiểm tra sau, bạn tạo lại vì mã bạn sẽ viết sẽ khó kiểm tra. Khi bạn kiểm tra trước, hoặc thậm chí kiểm tra một chút-một chút-giữa-nhưng-trước-khi-bạn-cam kết phần mềm bạn tạo sẽ dễ kiểm tra hơn. Một doanh nghiệp tạo ra các thử nghiệm đơn vị sau khi mã sản xuất được viết để đáp ứng danh sách kiểm tra là lãng phí công sức.

Việc tích hợp với phần mềm kiểm tra khó hiện có cũng sẽ tạo ra nỗ lực bổ sung, vì bạn sẽ cần tạo các đường nối thử nghiệm để có thể kiểm soát các phụ thuộc mà mã tiêu dùng thử nghiệm sáng bóng mới của bạn tiêu thụ. Trong một số trường hợp, chẳng hạn như với các khung sử dụng nhiều đối tượng nhà nước và thần toàn cầu, điều này có thể rất khó đạt được. Khó khăn nhận thức của sự phát triển theo hướng kiểm tra thường là do sự kết hợp thiếu kinh nghiệm với việc viết các bài kiểm tra tốt và cố gắng kiểm tra mã được ghép chặt chẽ.

Bạn có thể kiểm tra mã ổ đĩa ngay cả trong một dự án thác nước, nó là một ngành kỹ thuật không phải là một kỹ thuật quản lý dự án.

Tôi không phải là người cuồng TDD, nhưng nó dạy bạn rất nhiều về thiết kế phần mềm.

Chịu đựng tôi, vì điều này sẽ có một hương vị .Net đặc biệt: p

Đối với các loại dự án phù hợp với phương pháp thử nghiệm đầu tiên, một số điều tôi muốn tìm:

• bạn đang làm việc với một cơ sở mã hiện có? Nó thường rất tốn kém để trang bị thêm một bộ thử nghiệm. Hãy biết ý tưởng về khoản nợ kỹ thuật được thừa kế ở đó là bao nhiêu
• một số nền tảng và khung nhất định vốn đã không thân thiện. Kinh nghiệm gần đây xuất hiện trong tâm trí tôi - ví dụ như SharePoint rất khó (nhưng không phải là không thể) đối với TDD. Đối với những thứ như thế này, bạn có thể phải dùng đến một sản phẩm cách ly thương mại như TypeMock có thể giúp đỡ.
• phương pháp thực hiện nhất định cho vay TDD tốt hơn so với những cách khác. Ví dụ: ASP.Net với mã phía sau - không quá dễ kiểm tra. MVC MVC MVC - có thể kiểm tra. Silverlight với mã phía sau - không phải là thử nghiệm. Silverlight với MVVM - có thể kiểm tra.

Cuối cùng, trong khi "tổ chức" có thể làm rất nhiều để hỗ trợ cho việc chuyển sang thử nghiệm trước tiên, thì sự thay đổi quan trọng cần phải xảy ra là trong suy nghĩ của các nhà phát triển. Tôi đã từ bỏ phương pháp "bạn sẽ viết bài kiểm tra trước tiên" và thay vào đó hãy tìm những khoảnh khắc có thể dạy được.

+1 trên nhận xét của mpenrow về việc không nói với mgmt nếu họ có vấn đề với nó: p

Tình huống của bạn sẽ không thay đổi nhanh chóng, và chìa khóa để vượt qua nó là biến nó thành một phần của kỷ luật cá nhân của bạn, và phải giỏi về nó, trước khi cố gắng thúc đẩy nó vào người khác. Nếu bạn có thể là ví dụ về nó hoạt động thì người quản lý của bạn sẽ thấy lợi ích khách quan.

Bạn cũng có thể thực hiện các trường hợp kinh doanh tốt:

• TDD có thể được tóm tắt đơn giản là "thông số kỹ thuật mà hệ thống có thể tự động xác minh chính nó". Nó không lập trình khác nhau, nó không tạo ra một sản phẩm khác.

• Kiểm thử đơn vị thực sự chỉ là một hình thức kiểm thử tự động; vốn chỉ để máy tính tự làm những gì công ty có khả năng trả cho các kỹ sư không gian thịt để làm thủ công. Kiểm tra tự động chạy nhanh hơn, nhất quán hơn và - khi được viết tốt - cung cấp phản hồi và mô tả nhanh chóng, chính xác và chính xác cho vấn đề

• TDD, khi được thực hiện bởi một người biết họ đang làm gì, sẽ tạo ra kết quả nhanh như mã đầu tiên. Sẽ có một đường cong học tập / đào tạo (và, nếu các kỹ sư của bạn đến từ nhóm tài năng ngắn thì điều này hoàn toàn có thể giết chết cơ hội đẩy TDD của bạn - trong trường hợp này, điều tốt nhất bạn có thể làm là tiếp tục chiến thắng nó và làm quản lý câu hỏi họ chứ không phải là TDD)

• TDD rất quan tâm đến việc suy nghĩ thông qua nhiệm vụ trong tay trước khi bắt đầu nó. Theo dòng "đo hai lần, cắt một lần" - phép đo bổ sung thêm một lượng thời gian cận biên cho nhiệm vụ, nhưng tránh vứt bỏ tài nguyên quý giá nhất của bạn - giờ dev).

... và chỉ cần nhớ; điều quan trọng nhất bạn có thể làm là dẫn dắt bằng ví dụ. Nếu bạn khó tính với TDD, hãy đầu tư thêm một số giờ để làm việc tốt hơn. Khi bạn đã thành thạo, chỉ cần bắt đầu thực hiện tại nơi làm việc (người quản lý của bạn có thực sự phàn nàn rằng bạn viết bài kiểm tra không?). Chiến đấu một trận tại một thời điểm và thực hiện các bước về phía nó - vì toàn bộ shebang có thể sẽ dẫn đến thất bại và sự đổ lỗi sẽ đổ dồn lên bạn nếu bạn cố gắng hết sức vì nó.

Tôi làm. Đó là cách phát triển ưa thích của tôi và tôi làm việc cho một công ty tài chính lớn, người sẵn sàng cho tôi làm việc theo cách tôi thấy phù hợp miễn là tôi đáp ứng thời hạn và sản xuất mã chất lượng. Hoàn thành chính xác, kiểm tra phát triển đầu tiên không cần mất nhiều thời gian hơn kiểm tra sau phát triển và đừng quên phần thưởng khác của kiểm tra phát triển đầu tiên ít lỗi hơn trong kiểm tra hệ thống sau này.

Chìa khóa để thực hiện TDD là chỉ thực hiện nó như là một phần của việc viết mã của bạn và nếu cần, bạn không nói cho ai biết bạn đang làm điều đó. Không cần thiết phải giải thích mọi thứ bạn đang làm. Kết quả cuối cùng của bạn là mã làm việc.

Nếu bạn giải thích "Tôi đang viết bài kiểm tra", thì The Powers That Be có thể nói "Ồ, chúng ta có thể loại bỏ điều đó!" Nhưng nếu bạn không nói với ai, thì bạn vẫn có các bài kiểm tra như là dư lượng của quá trình mã hóa.

Lập trình không chỉ là gõ các câu lệnh làm việc vào một trình soạn thảo. Nếu mọi người không thể xử lý điều đó, thì hãy bảo vệ họ khỏi sự thật này cho đến khi họ sẵn sàng xử lý nó. "Sẵn sàng để xử lý nó" trong trường hợp này có nghĩa là khi bạn có một hoặc hai dự án hoàn thành, được thực hiện đúng thời gian với mã vững chắc, đáng tin cậy, và ồ, nhìn xem, bạn cũng có các bài kiểm tra đơn vị cho nó.

Thật buồn khi nói rằng, tôi đã không có cơ hội sử dụng nó trong thử nghiệm thực sự cổ điển - bản thân tôi, vì vậy tôi không thể nói "tôi! Tôi! Tôi làm điều đó!". Tôi giả định rằng câu hỏi là "những ngành / công ty nào sử dụng TDD trên bảng" chứ không phải "có ai có thể lén TDD vào cuộc sống hàng ngày của họ không?". Tôi đồng ý rằng một nhà phát triển cá nhân hoàn toàn có thể thực hiện TDD mà không buộc toàn bộ nhóm phải làm điều đó, tôi chỉ không nghĩ đó là điểm chính của câu hỏi.

Ấn tượng của tôi khi nghe xung quanh ngành là bạn có nhiều khả năng thấy TDD trên hầu hết các nhóm phát triển trong một công ty trong các tình huống:

• Không có cơ sở mã lớn hiện có trước khi bắt đầu TDD

• Công ty không lớn và do đó không có nhiều phản hồi "chúng tôi luôn làm theo cách khác".

• Công ty không có một khoản mua lớn vào quy trình chính thức. Điều đó không có nghĩa là bạn không thể triển khai TDD, ví dụ, một công ty được chứng nhận CMMI - nhưng nếu bạn có quy trình không phải TDD, thì tất cả các quy trình mà bạn theo dõi với CMMI được cập nhật có thể là một khoản đầu tư lớn.

• Các thử nghiệm có thể được viết kịch bản - đây là cơ sở mã phức tạp nhất, vì ngay cả khi bạn không thể dễ dàng viết kịch bản lớp gần nhất với người dùng, bạn có thể viết kịch bản một số nội bộ. Nhưng tôi thấy các tình huống với các tùy chọn được phát triển tốt để tự động hóa thử nghiệm là điểm ngọt ngào nhất đối với TDD, vì nó dựa trên việc chạy lại và không phá vỡ toàn bộ pin của các thử nghiệm mà bạn cần phản hồi về thử nghiệm rất nhanh. Tôi nghĩ rằng một ứng dụng web độc lập là một mục tiêu TDD tốt, một hệ thống tích hợp COTS chính hoặc đầu vào không dựa trên GUI có thể khó khăn.

• Các hệ thống ở trạng thái không nguyên mẫu. Lý tưởng nhất là phiên bản lớn tiếp theo sau nguyên mẫu - nơi bằng chứng về khái niệm đã kết thúc và dự án được tài trợ, nhưng mọi người đều biết rằng nỗ lực tiếp theo phải nhảy vọt về chất lượng.

• Các bên liên quan được đầu tư vào quá trình.

Tôi đã thử ở những nơi có thể - nhưng tôi nghĩ nó thực sự phù hợp với môi trường công ty nơi bạn tìm thấy chính mình. Tôi đã làm việc trong ngành công nghiệp trò chơi trong nhiều năm (với tư cách là một nghệ sĩ btw), và không có khái niệm về TDD - chỉ là một cách tiếp cận QA vũ phu. Tôi chuyển sang phát triển web và vẫn chưa làm việc trong một cơ quan với bất kỳ sự công nhận chính thức nào (hoặc kiến ​​thức về ...) thử nghiệm đơn vị / TDD. Điều tương tự cũng xảy ra với hầu hết các đồng nghiệp của tôi trong ngành, những người làm việc trong một loạt các ngành học.

Trong một đại lý tập trung vào bán hàng, TDD cung cấp rất ít ROI ngắn hạn cho khách hàng, và vì vậy thật khó để bán cho các nhà quản lý trực tuyến khi phân chia dự án. Tuy nhiên, một dự án càng lớn thì càng trở nên thuyết phục.

Cho rằng những cuốn sách như Death March chỉ ra một hiện tượng phổ biến, tức là một ngành công nghiệp bị ảnh hưởng bởi sự phát triển theo hướng "giòn" và "cột mốc" - tôi cho rằng TDD có lẽ hiếm khi xuất hiện bên ngoài các cửa hàng khởi nghiệp hoặc doanh nghiệp nguyên khối. Không phải là những người ở đó không tin vào giá trị của TDD - nhưng nó quá trừu tượng để bán cho khách hàng của họ.

Tôi đang cố gắng vào TDD. Tôi nghĩ miễn là bạn đi theo lộ trình mà bạn đã biết (công việc hàng ngày) thì khá đơn giản. Nhưng tôi chỉ không thể xoay quanh các bài kiểm tra cho các bộ phận UI hoặc khi bạn phải đưa ra một giải pháp mới cho một số vấn đề mà bạn chưa gặp phải trước đây. Hoặc sử dụng một khung mà bạn không biết.

Vì vậy, tôi đoán bạn phải thực hiện một số loại LearningTests, tách biệt các bằng chứng về khái niệm và viết lại sau đó, v.v. hay tôi sai?

Và (tôi biết đó là một câu hỏi cũ nhưng tôi chưa thấy câu trả lời hay): làm thế nào để bạn viết mã thuật toán bằng TDD (khi kết quả có thể phức tạp để thực sự "Khẳng định" một cách dễ dàng)?

Tôi thực sự có thể nhìn thấy những mặt tích cực của TDD và tôi đang ở trên thuyền nhưng rất khó cho người mới bắt đầu khi mã bạn viết sẽ khiến bạn mất gấp đôi thời gian (và bạn có những người ngang hàng không nhìn thấy ưu điểm và chế giễu bạn với RAD)

Tôi đã thử một vài lần và nó hoạt động rất tốt. Thật không may, hầu hết thời gian nếu tôi có thể tự kiểm tra ứng dụng của mình, tôi đã hoãn các bài kiểm tra đơn vị cho đến khi tôi cảm thấy quá chán để thực hiện một cái gì đó khác hoặc có một lỗi tôi không thể dễ dàng sửa chữa.

Tôi làm điều đó. Tiến trình của các câu chuyện người dùng của chúng tôi được theo dõi trên bảng Kanban, trong đó có "Đã kiểm tra?" cột bên trái (ngược dòng) của Phát triển.

Bố cục hơi bất thường này làm cho một chính sách rõ ràng: một thử nghiệm chấp nhận tự động thất bại (thông thường, một vài trong số chúng) phải tồn tại. Nó phải có thể truy nguyên theo yêu cầu của khách hàng. Các bài kiểm tra chấp nhận phát sinh từ các điều kiện thỏa mãn , kết quả từ các cuộc hội thoại bắt đầu bằng thẻ câu chuyện . Tôi tạo điều kiện cho các hội thảo thường xuyên nơi chúng tôi động não các yêu cầu, xác định các khoảng trống và tìm ra các thử nghiệm chấp nhận chính để đảm bảo giá trị người dùng được phân phối khi chúng vượt qua ( định nghĩa hoàn thành ). Đó là một hoạt động hợp tác liên quan đến các lập trình viên, nhà phân tích kinh doanh và đôi khi là người thử nghiệm.

Vòng phản hồi thử nghiệm chấp nhận khá dài: có thể mất vài ngày để hoàn thành câu chuyện. Sự phát triển có các vòng phản hồi TDD riêng, ngắn hơn.

"[... không có phong cách thử nghiệm đầu tiên ...] Giống với Agile hơn ...."

Đây là một sự trình bày sai hoàn toàn về Agile. Định nghĩa hoàn thành là một thành phần quan trọng của Agile và một trong những trụ cột mà nó dựa vào là thử nghiệm chấp nhận tự động (những gì tôi mô tả ở trên là một cách để làm điều đó.) Nếu lập trình cực đoan (XP) được sử dụng như một phương thức triển khai Agile, thì ATDD / BDD và TDD được quy định.

Tôi làm, nhưng nói chung chỉ dành cho các thành phần không phải ui và khi tôi biết tôi không thể giữ toàn bộ thuật toán cho một mô-đun trong đầu hoặc khi mô-đun là một phần mới của bất kỳ hệ thống nào tôi đang làm việc, vì vậy tôi không thể dựa vào phần lớn các thư viện mà tôi đang sử dụng để được gỡ lỗi cao.

Về cơ bản, tôi làm khi sự phức tạp của yêu cầu có nghĩa là tôi có thể bị lạc trong mã.

Đó là một thói quen khó khăn để bắt đầu và không yêu cầu quản lý mua, nhưng, khi các thử nghiệm của bạn bắt đầu vượt qua nửa chặng đường phát triển, nó có thể là một cứu tinh!

Tôi muốn hỏi chính câu hỏi này, để xem có bao nhiêu công ty đang thực sự thực hành TDD.

Trong 11 năm, tôi đã lập trình chuyên nghiệp, chỉ có hai tổ chức cuối cùng biết về TDD (kéo dài gần 5 năm, trước đó TDD không phổ biến như ngày nay). Tôi sẽ cắt theo đuổi và trả lời câu hỏi của bạn trước khi đi sâu vào mục đích bán hàng của tôi cho TDD :)

Tại công ty cuối cùng tôi làm việc (nhà xuất bản học thuật trực tuyến về các bộ sưu tập khoa học và nhân văn), chúng tôi biết rằng chúng tôi cần phải thực hành TDD nhưng chúng tôi chưa bao giờ đến đó. Để bảo vệ chúng tôi, chúng tôi đã có một cơ sở mã 250k, vì vậy việc thêm các bài kiểm tra vào một cơ sở mã không thể kiểm chứng có kích thước đó cảm thấy không thể vượt qua (tôi cảm thấy có lỗi khi gõ nó ngay bây giờ!). Ngay cả những người giỏi nhất trong chúng ta cũng mắc lỗi .

Bất cứ ai đã thực hiện ngay cả một lượng nhỏ TDD đều biết các bài kiểm tra trang bị thêm vào trường màu nâu có thể gây đau đớn đến mức nào ... Nguyên nhân chính là do phụ thuộc ngầm (bạn không thể kéo tất cả các đòn bẩy để xác nhận kết quả từ mã - bạn không thể giả định kịch bản) và vi phạm nguyên tắc trách nhiệm duy nhất (các bài kiểm tra rất phức tạp, bị chiếm đoạt, yêu cầu thiết lập quá nhiều và khó hiểu ).

Chúng tôi tạm thời phát triển nhóm QA của chúng tôi (từ một, có thể hai người đến nửa tá hoặc hơn) để kiểm tra nền tảng trước khi phát hành. Đó là thời gian cực kỳ tốn kém về mặt tài chính và tài chính, một số bản phát hành sẽ mất ba tháng để hoàn thành 'thử nghiệm'. Ngay cả sau đó chúng tôi biết rằng chúng tôi đang vận chuyển với các vấn đề, họ chỉ không phải là 'chặn' hoặc 'quan trọng', chỉ là 'ưu tiên cao'.

Nếu bạn có kinh nghiệm thương mại nhiều năm, bạn sẽ đánh giá cao rằng mọi công ty đều thực hiện các nhiệm vụ quan trọng , và sau đó phát minh ra mức độ ưu tiên cao hơn mức đó và rất có thể là ở trên đó - đặc biệt là khi ai đó ở trên đang đẩy mạnh tính năng / sửa lỗi. Tôi lạc đề ...

Tôi rất vui khi báo cáo Tôi đang thực hành TDD trong công ty hiện tại của mình (nhà phát triển ứng dụng viễn thông, web và di động), cùng với Jenkins CI để đưa ra các báo cáo phân tích tĩnh khác (phạm vi bảo hiểm mã là hữu ích nhất sau khi xác nhận bộ thử nghiệm vượt qua) . Các dự án tôi đã sử dụng TDD trên là một hệ thống thanh toán và hệ thống điện toán lưới.

Doanh số ...

Nó thường có thể là một cuộc đấu tranh khó khăn để chứng minh thử nghiệm tự động cho các thành viên nhóm phi kỹ thuật. Viết bài kiểm tra sẽ bổ sung thêm nhiều công việc cho quá trình phát triển nhưng ... thời gian bạn đầu tư vào thử nghiệm ngay bây giờ, bạn sẽ tiết kiệm được công sức bảo trì sau này. Bạn thực sự chỉ đang mượn thời gian . Sản phẩm được sử dụng càng lâu, bạn càng tiết kiệm nhiều hơn - và nó sẽ giúp bạn tránh được việc viết lại lớn .

Kiểm tra trước có nghĩa là bạn đang mã hóa ý định của mình trước, sau đó xác nhận mã của bạn hoàn thành ý định đó. Điều này cung cấp trọng tâm và chắt lọc mã của bạn để chỉ làm những gì được dự định và không còn nữa (đọc không phình to). Đó là một đặc tả và tài liệu thực thi cùng một lúc (nếu bài kiểm tra của bạn được viết tốt và các bài kiểm tra phải dễ đọc / sạch như mã hệ thống của bạn, nếu không muốn nói thêm!).

Những người không lập trình sẽ (thường) sẽ không có cái nhìn sâu sắc này và vì vậy TDD không giữ được nhiều giá trị cho họ và được coi là lối tắt dùng một lần đến ngày phát hành sớm hơn.

Lập trình là lĩnh vực của chúng tôi , và trong suy nghĩ của tôi, điều này khiến chúng tôi có trách nhiệm , là chuyên gia, phải tư vấn về thực tiễn tốt nhất như TDD. Không phải để các nhà quản lý dự án quyết định liệu nó có được thực hiện để giảm thời gian phát triển hay không, nó nằm ngoài phạm vi quyền hạn của họ . Cũng giống như cách họ không cho bạn biết nên sử dụng khung, giải pháp bộ đệm hoặc thuật toán tìm kiếm nào, họ không nên cho bạn biết nếu bạn nên sử dụng thử nghiệm tự động.

Theo tôi , ngành công nghiệp phát triển phần mềm (nói chung) hiện tại đã bị phá vỡ, thực tế là việc kiểm tra phần mềm của bạn KHÔNG phải là chuẩn mực.

Hình ảnh này trong các ngành công nghiệp khác: y tế, hàng không, ô tô, mỹ phẩm, đồ chơi mềm, đồ uống có cồn, v.v. Tôi đã yêu cầu vị hôn thê của tôi đặt tên cho một ngành công nghiệp nơi họ không thử nghiệm sản phẩm và cô ấy không thể!

Có lẽ thật không công bằng khi nói không có thử nghiệm xảy ra bởi vì nó ... nhưng trong các công ty không có thử nghiệm tự động, đó là quá trình rất thủ công / con người (đọc vụng về và thường dễ bị lỗi).

Một điểm tôi sẽ tranh luận trong câu hỏi của bạn ...

Họ thường muốn phát triển bắt đầu ngay lập tức, hoặc sau một thời gian ngắn thiết kế. Gần giống với Agile.

Là "Agile" không quy định tiến hành mà không có xét nghiệm, thành viên đầu tiên được liệt kê trên agilemanifesto.org là Kent Beck , người tạo ra XP và TDD!

Hai cuốn sách tôi rất muốn giới thiệu nếu bạn quan tâm đến TDD, hoặc chưa đọc chúng và là một lập trình viên sắc sảo (tất cả mọi người đều đọc đúng không?)

Phát triển phần mềm hướng đối tượng được hướng dẫn bởi các thử nghiệm

Clean Code - Sê-ri Robert C Martin ("Chú Bob")

Hai cuốn sách này khen nhau và cô đọng rất nhiều ý nghĩa vào vài trang.

Cảm ơn đã hỏi câu hỏi này :)

Những người thực hiện nhân bản. Tôi không thể nghĩ ra một quy trình tốt hơn khi bạn phát triển một thứ gì đó, hoạt động chính xác như một chương trình hiện có.

Rõ ràng đây là một trường hợp khá bất thường, nhưng các nhà phát triển SQLite sử dụng các bài kiểm tra rộng rãi. (Tôi cho rằng quá trình phát triển của họ là thử nghiệm đầu tiên, mặc dù tôi không chắc chắn.)

• 73.000 dòng mã
• 91.378.600 dòng mã kiểm tra

Xem http://www.sqlite.org/testing.html