Làm thế nào để sử dụng BDD để kiểm tra đơn vị trình biên dịch?

Nhóm của tôi đang viết một trình biên dịch cho một ngôn ngữ dành riêng cho miền (DSL) sẽ được tích hợp vào IDE. Ngay bây giờ, chúng tôi đang tập trung vào giai đoạn phân tích của trình biên dịch. Chúng tôi không sử dụng bất kỳ trình tạo trình phân tích cú pháp hiện có nào (như ANTLR) vì chúng tôi cần hiệu suất thời gian thực và thông tin lỗi / cảnh báo / thông báo rất chi tiết. Chúng ta có

1. các lớp, mỗi lớp đại diện cho một nút trong cây cú pháp cụ thể cho ngôn ngữ, cũng như
2. các lớp đóng vai trò là chú thích cho mỗi nút (nghĩa là có lỗi và thông tin bổ sung), cũng như
3. các lớp bên trong xây dựng và thao tác cây cú pháp cụ thể (ví dụ: lexer, trình phân tích cú pháp, bộ đệm cho chuỗi, khách truy cập cú pháp).

Chúng tôi đang cố gắng quyết định một chiến lược tổng thể để tổ chức các bài kiểm tra của chúng tôi. Công ty chúng tôi đang thúc đẩy phát triển dựa trên hành vi (BDD) và thiết kế theo hướng tên miền (DDD). Mặc dù chúng tôi đang xây dựng DSL cho miền của công ty chúng tôi, miền của trình biên dịch là ngôn ngữ lập trình.

Chúng tôi vẫn đang trong quá trình xây dựng trình biên dịch và đã có một số thử nghiệm. Chúng tôi đang hướng tới mục tiêu bảo hiểm 100%.

Hiện tại chúng tôi có các thử nghiệm trong đó chúng tôi nhập mã nguồn vào trình tạo cây cú pháp và sau đó chạy xác minh trên từng thuộc tính của mỗi nút của cây cú pháp kết quả để đảm bảo rằng thông tin dự kiến ​​(số dòng, lỗi liên quan, con / mã thông báo gốc, chiều rộng của mã thông báo, loại mã thông báo, v.v.). Bây giờ, vì mỗi nút là lớp riêng của nó và các chú thích và lỗi nhất định được gắn vào một nút là các lớp riêng biệt, bài kiểm tra này kết thúc bằng cách tham chiếu nhiều lớp.

Hiện tại chúng tôi có các bài kiểm tra cho một số lớp nhất định như lexer trong đó chúng tôi có thể cô lập đầu vào (một chuỗi) và đầu ra (một danh sách các mã thông báo) từ các lớp khác (ví dụ: các lớp cho các nút của cây cú pháp). Những xét nghiệm này có nhiều chi tiết.

Bây giờ, các bài kiểm tra trong đoạn ngay trên có thể được đặt tương ứng với lớp được kiểm tra (ví dụ: lexer, bộ đệm chuỗi). Tuy nhiên, các thử nghiệm từ đoạn thứ hai ở trên thực sự kiểm tra toàn bộ giai đoạn phân tích của trình biên dịch; nghĩa là, mỗi thử nghiệm có thể có hơn 300 xác nhận cho cây cú pháp, được cung cấp mã nguồn đầu vào. Các xét nghiệm dành cho hành vi của giai đoạn phân tích.

Đây có phải là một chiến lược thử nghiệm thích hợp? Nếu không, chúng ta nên làm gì khác nhau? Chiến lược tổ chức nào chúng ta nên sử dụng cho các thử nghiệm của mình?

  > Is this an appropriate testing strategy?

Không , bởi vì tên miền phụ của bạn là DSL (một loại ngôn ngữ lập trình) và trình biên dịch của bạn là một phần của chi tiết triển khai cho trường hợp sử dụng cho phép tự động hóa các hành động / quy trình công việc trong miền này bằng DSL.

Vì tôi không biết làm thế nào vẻ DSL của bạn như tôi giả sử rằng bạn có khái niệm như loop, condition, statement, variablesử dụng ví dụ

 for(int i=1;i =< 10;i++) {subtask();}

Sử dụng ngôn ngữ giống như ngôn ngữ bạn có thể viết một cái gì đó như

as a automation user
i want to have a for loop with startvalue, endvalue, loopincrement
so that i can repeat subtasks several times.

given startvalue=1
and endvalue = 10
and loopinclrement = 1
when i execute for(int i=%startvalue%;i =< %endvalue %;i+=%loopinclrement%)
then the subtask should have been executet 10 times.

Đây là khá nhiều công việc để chứng minh rằng trình biên dịch của bạn hoạt động như mong đợi.

  > If not, what should we be doing differently? 
  > What organization strategy should we use for our tests?

Tôi sẽ tạo ra một kho lớn các ví dụ cho đầu vào với đầu ra tương ứng.

Kiểm tra tự động sẽ lặp qua các ví dụ và xác minh rằng đầu ra của trình biên dịch khớp với đầu ra dự kiến.

Ví dụ: nếu dsl liên quan đến hóa đơn / đơn hàng của bạn biên dịch sang java, một mục lưu trữ sẽ trông như sau:

 example: loop over orderentries
 dsl-source: foreach orderitem in orders do calculateTaxes(orderitem)
 expected errormessage: none
 expected java output: for(OrderItemType orderitem : orders) 
                          {calculateTaxes(orderitem);}

 example: loop with syntax errors
 dsl-source: foreach orderitem in orders 
 expected errormessage: missing "do"-keyword in line 1
 expected java output: none

Vì vậy, thay vì viết nhiều mã để phù hợp với bdd, bạn chỉ cần thêm các ví dụ về giá trị đầu vào / đầu ra được mã hóa cứng.