Giả thuyết, phản đề, tổng hợp

Hegel là nỗ lực mang lại chất lượng của thử nghiệm dựa trên thuộc tính có trong Giả thuyết cho mọi ngôn ngữ và làm cho tính năng này tích hợp liền mạch với Antithesis để tăng khả năng tìm lỗi của nó. Hôm nay chúng tôi sẽ phát hành Hegel cho Rust, nhưng đây là thư viện đầu tiên trong số nhiều thư viện. Chúng tôi dự định phát hành Hegel cho Go trong một hoặc hai tuần tới và chúng tôi đã có các thư viện Hegel ở nhiều trạng thái sẵn sàng khác nhau cho C++, OCaml và TypeScript mà chúng tôi dự định phát hành trong những tuần hoặc tháng tới.

Đây là một ví dụ từ Hegel dành cho Rust để kích thích sự thèm ăn của bạn:

#[hegel::kiểm tra(test_cases = 1000)] 
fn test_section_parse_robustness(tc: hegel::TestCase) {
 let s: Chuỗi = tc.vẽ(trình tạo::văn bản());
 hãy để _ = Phân số::from_str(&s); // đừng bao giờ hoảng sợ

Thử nghiệm dựa trên thuộc tính là gì?

Chúng ta đã thấy một ví dụ ở trên với Hegel dành cho Rust: Thử nghiệm dựa trên thuộc tính là thử nghiệm trong đó, thay vì tự cung cấp trường hợp thử nghiệm cụ thể đầy đủ, bạn sử dụng thư viện để chỉ định một phạm vi giá trị mà thử nghiệm sẽ vượt qua. Trong ví dụ về phân số, xác nhận quyền sở hữu của chúng tôi là một tuyên bố chung: Trình phân tích cú pháp của chúng tôi không bao giờ bị lỗi mà phải luôn tạo ra kết quả hợp lệ hoặc giá trị lỗi.

Bạn có thể coi thử nghiệm dựa trên thuộc tính đó là vô số bản sao của thử nghiệm trông giống như sau, trong đó mỗi thử nghiệm thay thế giá trị s bằng một chuỗi khác:

#[ kiểm tra
fn test_section_parse_robustness() {
 hãy s: Chuỗi = "0/0";
 cho _ = Phân số::from_str(&s ); // đừng bao giờ hoảng sợ

Lợi ích của thư viện thử nghiệm dựa trên thuộc tính là bạn không cần phải nghĩ ra những chuỗi đó.

“Không gặp sự cố” có lẽ là bài kiểm tra dựa trên thuộc tính nhàm chán nhất, nhưng nó lại hữu ích một cách đáng ngạc nhiên. Đến từ Python, nó rất hữu ích (thật khó để viết một chương trình Python không bao giờ gặp sự cố), nhưng như chúng ta đã thấy, điều này xảy ra ngay cả trong Rust.

Đây là một ví dụ khác về thuộc tính chung thú vị hơn:

sử dụng hegel::trình tạo::{self, Trình tạo, số nguyên, boolean};
sử dụng gỉ_thập phân::Thập phân;
sử dụng std::str::FromStr;

#[hegel::tổng hợp]
fn thập phân_gen( tc: hegel::TestCase) -> Thập phân {
 let int_part = tc.rút(số nguyên::<i64>());
 hãy để has_frac = tc .hòa(booleans());
 nếu has_frac {
 hãy frac_digits = tc.rút(số nguyên::<u32>()
 .min_value(1 ).max_value(28));
 hãy frac_val = tc.rút(số nguyên::<u64>()
 .max_value(10u64.saturating_pow (frac_digits.phút(18))));
 hãy để s = định dạng!("{.{:0>width$}", int_part, frac_val,
 chiều rộng = frac_digits khi sử dụng);
 Thập phân::from_str(&s).unwrap_or(Thập phân::từ(int_part))
  khác {
 Thập phân ::từ(int_part)
 


#[hegel::kiểm tra(test_case = 1000)]
fn test_decimal_scientific_roundtrip(tc: hegel ::TestCase) {
 hãy d = tc.rút ra(decimal_gen());
 hãy để định dạng sci =!("{:e}", d);
 hãy để phân tích cú pháp = Số thập phân::from_scientific(&sci)
 .mong đợi(&format!("Không thể phân tích cú pháp {:? từ {}", khoa học viễn tưởng, d ));
 khẳng định_eq!(d, được phân tích cú pháp);

Ở đây, chúng tôi phải xác định trình tạo tùy chỉnh của riêng mình cho Thập phân bằng cách sử dụng sự hỗ trợ của Hegel để soạn các trình tạo. Sau đó, chúng tôi phải kiểm tra một thuộc tính chung được gọi là "gấp vòng" - nếu bạn tuần tự hóa một giá trị thành một số định dạng và sau đó đọc lại, bạn sẽ nhận được giá trị tương tự. Đây có lẽ là một trong những thuộc tính không tầm thường phổ biến nhất đáng để thử nghiệm trong hầu hết các dự án, vì hầu hết phần mềm đều cần chuyển đổi dữ liệu giữa các định dạng khác nhau tại một số điểm. Trong trường hợp này, hóa ra rust_decimal không xử lý chính xác số 0 khi chuyển đổi số thành ký hiệu khoa học và thử nghiệm này đã tìm ra lỗi.

Tôi có một phân loại sơ bộ về các lỗi được phát hiện bằng thử nghiệm dựa trên thuộc tính và chia thành ba loại:

1. Bạn đã quên số 0.
2. Kiểu dữ liệu này bị nguyền rủa và bạn đã phạm phải lời nguyền đó.
3. Bạn đã mắc lỗi trong một bất biến cấu trúc phức tạp.

Tại Antithesis, chúng tôi hào hứng nhất với danh mục thứ ba, nhưng nhìn chung tôi nhận thấy phần lớn giá trị ban đầu của thử nghiệm dựa trên thuộc tính đến từ việc loại bỏ hai danh mục đầu tiên, vì các lỗi thuộc loại này rất dễ tìm thấy.

Ví dụ: đây là thử nghiệm cho thấy heck chạy vi phạm Unicode bị nguyền rủa (lỗi được báo cáo):

sử dụng chết tiệt::ToTitleCase;

#[hegel ::kiểm tra(test_case = 1000)]
fn test_title_case_idempotent(tc: hegel::TestCase) {
 let s: Chuỗi = tc. draw(máy phát điện::text());
 hãy một lần = s.to_title_case();
 hãy hai lần = một lần.to_title_case();
 khẳng định_eq!(một lần , hai lần);

Điều này kiểm tra thuộc tính trực quan rằng một khi bạn đã chuyển đổi nội dung nào đó thành trường hợp tiêu đề thì nội dung đó sẽ ở dạng trường hợp tiêu đề và không cần thay đổi thêm. Thật không may, điều này không thành công khi vẽ “ß”, to_title_case đầu tiên biến thành "SS", to_title_case đầu tiên biến thành "SS" và "Ss".

Ví dụ tốt nhất mà tôi đưa ra cho bạn ngay bây giờ về “các bất biến cấu trúc phức tạp” xuất phát từ lỗi này (hóa ra là đã được biết) mà Hegel tìm thấy trong im thư viện:

#[hegel::kiểm tra(test_cases = 1000)]
fn test_ordmap_get_prev(tc: hegel::TestCase) {
 // Thủ thuật tăng kích thước để đảm bảo chúng tôi thử nghiệm trên các bộ khóa lớn.
 hãy n = tc.draw(máy phát điện::số nguyên::<usize>().max_value(200));
 cho phép phím:  Vec<i32> = tc.draw(máy phát điện::vecs(máy phát điện::số nguyên()).min_size(n));

 hãy để im_map: OrdMap<i32, i32> = khóa.iter().map(|&k| (k, k)).thu thập();
 hãy bt_map: BTreeMap<i32, i32> = khóa.iter().map(|&k| (k, k)).thu thập();

 hãy để khóa = tc.rút(máy phát điện::số nguyên::<i32>());
 let im_prev = im_map.get_prev(&key).map(|(k, v)| (*k, *v));
 hãy bt_prev = bt_map.phạm vi(..=key).next_back().map(|(&k, & v)| (k, v));
 khẳng định_eq!(im_prev, bt_prev, "get_prev({) không khớp với { khóa", khóa, im_map. len());

Điều này cho thấy trên một kích thước nhất định, get_prev trả về giá trị sai.

Loại thử nghiệm này là một ví dụ đơn giản về cái mà chúng tôi thường gọi là “thử nghiệm dựa trên mô hình” - bạn có thứ gì đó muốn thử nghiệm và bạn xây dựng một “mô hình” về nó - thường là một số triển khai không tốt của cùng một thứ, ví dụ: lưu trữ mọi thứ trong bộ nhớ hoặc thực hiện mọi thứ không hiệu quả. Sau đó, bạn có thể sử dụng thử nghiệm dựa trên thuộc tính để kiểm tra xem mô hình và thực tế có luôn giống nhau hay không.

Có nhiều cách khác để sử dụng thử nghiệm dựa trên thuộc tính hơn cách này. Bài đăng này chỉ giới thiệu một số loại bài kiểm tra hiệu quả hơn mà bạn có thể viết bằng nó. Khi bắt đầu, tôi thực sự có xu hướng khuyên bạn bắt đầu với một trong các thử nghiệm hiện có của bạn và tái cấu trúc nó, nhưng khi bạn bắt đầu nghĩ đến loại thử nghiệm này, bạn sẽ bắt đầu thấy các ví dụ giống như những thử nghiệm trên ở khắp mọi nơi.

Giả thuyết là gì?

Nếu bạn chưa quen với nó, Giả thuyết là thư viện thử nghiệm dựa trên thuộc tính được sử dụng rộng rãi nhất trên thế giới.

Một số lý do tại sao Giả thuyết là thư viện được sử dụng rộng rãi nhất thuộc loại này là vì nó được viết bằng Python, loại thư viện mà tôi được biết là có rất ít người dùng. Nhưng Giả thuyết không phải là thư viện thử nghiệm dựa trên thuộc tính đầu tiên trong Python, mà chỉ là thư viện đầu tiên được sử dụng rộng rãi. Điều này là do nó có rất nhiều lợi ích so với các thư viện thử nghiệm dựa trên thuộc tính khác.

Một ý tưởng hơi điên rồ

Trong ngắn hạn, kế hoạch này ít nhiều đã có tác dụng! Hegel vẫn chưa đặc biệt giỏi trong việc thử nghiệm loại hệ thống phân tán đồng thời cao, vốn là nền tảng của thử nghiệm Phản đề - nó phần lớn thừa hưởng những hạn chế của Giả thuyết về mặt này. Vì vậy, chúng tôi nghĩ Phản đề sẽ tuyệt vời nếu bạn đang viết các bài kiểm tra Hegel và bạn muốn mạnh mẽ hơn một chút, nhưng Hegel đôi khi sẽ chỉ tuyệt vời nếu bạn có Phản đề và muốn cải thiện bài kiểm tra của mình về nó. Tuy nhiên, hãy xem không gian này! Hy vọng chúng tôi sẽ có thêm một số thông tin cập nhật về vấn đề đó trong những tháng tới.

Tại sao bạn nên sử dụng Hegel?

Rõ ràng là tôi có thành kiến, nhưng tôi thực sự nghĩ Hegel sẽ đóng vai trò quan trọng trong tương lai của cách chúng ta phát triển phần mềm. Tôi nghĩ rằng ngay cả khi chúng tôi hiện không thực hiện các quy trình làm việc dựa trên AI để thay đổi mọi thứ, nhưng chúng tôi đang làm như vậy và điều đó tạo nên sự khác biệt lớn.

Vì Liam gần đây đã trình bày rõ ràng nên thử nghiệm dựa trên thuộc tính sẽ đóng vai trò quan trọng trong cách chúng tôi giúp quá trình phát triển phần mềm dựa trên tác nhân AI không diễn ra quá tệ. Đối với những người sử dụng thử nghiệm dựa trên thuộc tính như chúng tôi, đây đã là một phần quan trọng trong cách chúng tôi giúp việc phát triển phần mềm dựa trên con người không diễn ra quá tệ trong vài thập kỷ qua, nhưng tất cả những lợi thế mà chúng tôi đang hướng tới giờ đây trở nên cực kỳ quan trọng.

Trước đây, tôi đã thực hiện rất nhiều công việc về đánh giá AI và một trong những điều luôn nổi bật là số lần AI vượt qua đánh giá mã hóa, sau đó bạn thêm các thử nghiệm dựa trên thuộc tính và thấy rằng một phần đáng kể các giải pháp của nó hiện đã thất bại (công bằng mà nói, đây cũng là trải nghiệm của con người viết mã và thử nghiệm dựa trên thuộc tính lần đầu tiên). AI đã trở nên tốt hơn nhiều kể từ đó, nhưng mã của nó vẫn còn cẩu thả vì muốn có một từ tốt hơn và chúng ta cần các công cụ để bù đắp cho điều đó.

Nhưng điều ngược lại là việc bắt đầu thử nghiệm dựa trên thuộc tính cũng chưa bao giờ dễ dàng hơn trước vì các đại lý thực sự viết bài kiểm tra khá giỏi! Tôi phải thú nhận: Tất cả những ví dụ về lỗi mà chúng tôi tìm thấy khi sử dụng Hegel? Tôi không viết chúng. Claude đã làm vậy.

Cùng với các thư viện Hegel cốt lõi, chúng tôi cũng đang phát hành Kỹ năng Hegel để yêu cầu nhân viên viết bài kiểm tra dựa trên thuộc tính cho bạn. Tôi không nghĩ nó có thể - hoặc nên - thay thế bạn viết bài kiểm tra dựa trên thuộc tính của riêng bạn, nhưng phần khó nhất của kiểm tra dựa trên thuộc tính đối với mọi người dường như luôn là viết bài kiểm tra đầu tiên, vì nó buộc bạn phải suy nghĩ nhiều hơn về cách tạo dữ liệu để kiểm tra mã của bạn. Để một người đại diện giúp bạn vượt qua khó khăn ban đầu đó sẽ là một chiến thắng lớn.

Tất nhiên, tất cả những điều này là lập luận cho rằng bạn nên sử dụng kiểm tra dựa trên đặc tính, thay vì sử dụng Hegel nói riêng. Tại sao bạn nên sử dụng Hegel nói riêng?

Chà, nếu bạn đã có những bài kiểm tra dựa trên thuộc tính tuyệt vời mà bạn hài lòng thì có lẽ bạn không nên làm vậy. Hegel vẫn còn ở giai đoạn đầu và mặc dù chúng tôi muốn nó trở thành thư viện thử nghiệm dựa trên thuộc tính tốt nhất trong mọi ngôn ngữ và tự tin rằng chúng tôi sẽ đạt được điều đó, nhưng chúng tôi không thể phủ nhận rằng nó còn có một số khó khăn. Như đã nói, nếu bạn vẫn muốn kiểm tra nó, tôi cá rằng Claude sẽ nhanh chóng chuyển các bài kiểm tra hiện có của bạn sang nó và bạn có thể tự quyết định xem mình thích cái nào hơn (và nếu đó là những bài kiểm tra hiện có, chúng tôi thực sự đánh giá cao việc bạn cho chúng tôi biết lý do để chúng tôi có thể khắc phục nó!).

Mặt khác, nếu bạn muốn bắt đầu thử nghiệm dựa trên thuộc tính trên lĩnh vực xanh thì chúng tôi cho rằng Hegel là nơi tuyệt vời để thực hiện điều đó. Nó thừa hưởng rất nhiều sức mạnh từ cốt lõi Giả thuyết và chúng tôi đã làm cho nó dễ sử dụng nhất có thể.

Tiếp theo là gì

Trước mắt, mục tiêu quan trọng mà chúng tôi đang thực hiện là Hegel cho các ngôn ngữ khác. Như đã đề cập, chúng tôi đã có Go, C++, OCaml và TypeScript đang hoạt động ở nhiều mức độ sẵn sàng khác nhau. Dự kiến sẽ thấy một số hoặc tất cả những điều này trong những tuần tới.

Bên cạnh đó, việc hỗ trợ người dùng cũng như các yêu cầu tính năng và báo cáo lỗi không thể tránh khỏi mà chúng tôi mong đợi/hy vọng nhận được, chúng tôi sẽ hơi bận rộn trong thời gian ngắn nhưng chúng tôi cũng sắp có một số kế hoạch đầy tham vọng hơn.

Chúng tôi muốn loại bỏ sự phụ thuộc Python vào Hegel. Ngoài việc khá kỳ lạ, nó chắc chắn là công cụ giới hạn hiệu suất hiện tại khi chạy các bài kiểm tra Hegel. Kế hoạch dài hạn hiện tại của chúng tôi là triển khai máy chủ Hegel thứ hai ở Rust, nhưng chúng tôi không hứa hẹn điều này sẽ xảy ra hoặc cam kết về bất kỳ mốc thời gian nào.

Sau đó, ưu tiên hàng đầu của chúng tôi là giúp Hegel xử lý tốt hơn loại khối lượng công việc mà Antithesis tỏa sáng. Hiện tại, chúng tôi hy vọng nó sẽ hoạt động tốt đối với loại thử nghiệm dựa trên thuộc tính truyền thống mà Giả thuyết đã làm tốt, nhưng chúng tôi đang tìm cách mở rộng nó để hoạt động tốt hơn ở các thử nghiệm đồng thời và không xác định cao.

Chúng tôi rất vui nếu bạn kiểm tra Hegel và cho chúng tôi biết về bất kỳ lỗi nào bạn tìm thấy với nó, cho dù chúng nằm trong mã của bạn hay của chúng tôi!