2010-06-21 36 views
11

Tôi đang tìm cách chạy thử nghiệm trên các tiện ích dòng lệnh được viết bằng bash hoặc bất kỳ ngôn ngữ nào khác.kiểm tra các tiện ích dòng lệnh

Tôi muốn tìm một khuôn khổ kiểm tra mà có thể có những câu như

setup: 
    command = 'do_awesome_thing' 
    filename = 'testfile' 
    args = ['--with', 'extra_win', '--file', filename] 
    run_command command args 

test_output_was_correct 
    assert_output_was 'Creating awesome file "' + filename + '" with extra win.' 

test_file_contains_extra_win 
    assert_file_contains filename 'extra win' 

Có lẽ trường hợp kiểm tra cơ sở sẽ thiết lập một thư mục tạm trong đó để chạy các lệnh sau, và loại bỏ nó ở teardown.

Tôi muốn sử dụng một cái gì đó bằng Python, vì tôi quen thuộc hơn nhiều so với các ngôn ngữ ứng viên hợp lý khác.

Tôi tưởng tượng rằng có thể có điều gì đó sử dụng DSL để làm cho ngôn ngữ không thuyết phục có hiệu quả về ngôn ngữ (hoặc ngôn ngữ riêng của nó, tùy thuộc vào cách bạn nhìn vào nó); tuy nhiên điều này có thể ít hơn lý tưởng, vì các kỹ thuật thử nghiệm của tôi thường liên quan đến việc viết mã để tạo ra các thử nghiệm.

Đó là một chút khó khăn để google cho điều này, vì có rất nhiều thông tin về tiện ích chạy thử nghiệm, đó là loại trò chuyện của những gì tôi đang tìm kiếm.

Hỗ trợ cho doctests nhúng trong đầu ra của command --help sẽ là một tiền thưởng thêm :)

+1

Bạn có thể nhận được một số thông tin hữu ích từ một câu hỏi mà tôi đã hỏi về tập lệnh shell thử nghiệm đơn vị: http://stackoverflow.com/questions/971945/unit-testing-for-shell-scripts –

+0

@gareth_bowles: cool, cảm ơn vì liên kết. Tôi có thể thử sử dụng shunit2 nếu nó tương thích với bash. – intuited

Trả lời

13

Check-out ScriptTest:

from scripttest import TestFileEnvironment 

env = TestFileEnvironment('./scratch') 

def test_script(): 
    env.reset() 
    result = env.run('do_awesome_thing testfile --with extra_win --file %s' % filename) 
    # or use a list like ['do_awesome_thing', 'testfile', ...] 
    assert result.stdout.startswith('Creating awesome file') 
    assert filename in result.files_created 

Đó là doctest sử dụng được một cách hợp lý là tốt.

+0

Âm thanh tuyệt vời! Cảm ơn! – intuited

1

Vâng ... Những gì chúng ta thường làm (và là một trong những kỳ quan của ngôn ngữ OO) là viết tất cả các thành phần của một ứng dụng trước khi thực sự tạo ứng dụng. Mỗi thành phần có thể có một cách độc lập để thực hiện, cho mục đích thử nghiệm (dòng lệnh, thường), điều đó cũng cho phép bạn suy nghĩ trong đó là các chương trình hoàn chỉnh từng chương trình và sử dụng chúng trong các dự án trong tương lai. Nếu những gì bạn muốn là kiểm tra tính toàn vẹn của một chương trình hiện có ... tốt, tôi nghĩ cách tốt nhất là học sâu như thế nào nó hoạt động, hoặc thậm chí sâu hơn: đọc nguồn. Hoặc thậm chí sâu hơn: phát triển một bot để thử nghiệm nó: 3

Xin lỗi đó là những gì tôi có .-.

+0

Chắc chắn .. đó là một cách tuyệt vời để làm việc. Tôi thu thập rằng những gì bạn mô tả sẽ được gọi là "thử nghiệm đơn vị", trong khi tôi muốn một bộ công cụ để làm "kiểm tra chấp nhận" hoặc "thử nghiệm chức năng" hoặc "thử nghiệm tích hợp". Điều này một phần là cung cấp một phương tiện bổ sung để xác minh mã là đơn vị có thể kiểm thử và cũng cho phép một số loại thử nghiệm trên mã không phải là đơn vị có thể kiểm thử được: bash scripts (chặn sự tồn tại của —shudder— một khung kiểm thử đơn vị bash); các tiện ích độc quyền ngoài nhà hoạt động theo các cách kém tài liệu; hoặc mã trong đó một sự phức tạp của các khía cạnh được trộn lẫn trong một thói quen duy nhất. – intuited

+0

Ngoài ra: để phù hợp với thuật ngữ của bạn, tôi đoán những gì tôi đang tìm kiếm là một "khuôn khổ bot". – intuited

+0

những gì tôi hiểu bạn muốn làm là để tìm một thử nghiệm chung cho các chương trình với CLI? Tôi thấy nó thật khó để nhận ra, bởi vì một chương trình quá xấu nên không thể đoán trước được. Nếu bạn gặp phải một phần mềm sai, và nguồn của nó không có sẵn, lựa chọn tốt nhất có vẻ là: hãy thử tìm kiếm các chương trình tương tự. Hay tại sao không? đăng sự cố của bạn trong diễn đàn:] OK hay tôi đã bỏ lỡ điều gì đó? Nếu tôi đã làm, hãy cố gắng rõ ràng hơn về trường hợp cá nhân của bạn. – sadasant

0

bên ngoài bất kỳ khung kiểm tra đóng gói sẵn nào có thể tồn tại nhưng tôi không biết, tôi sẽ chỉ ra rằng kỳ vọng là một công cụ tuyệt vời và không được tận dụng cho loại tự động hóa này, đặc biệt là nếu bạn muốn hỗ trợ tương tác nhiều tầng để nói không chỉ gửi một lệnh và kiểm tra đầu ra mà còn trả lời đầu ra với nhiều đầu vào hơn. Nếu bạn xây dựng hệ thống của riêng bạn, nó đáng xem xét.

Ngoài ra còn có triển khai lại python của kỳ vọng được gọi là pexpect.There có thể có một số giao diện trực tiếp đến thư viện mong đợi có sẵn. Tôi không phải là một anh chàng python vì vậy tôi không thể cho bạn biết nhiều về họ.

1

Tôi biết rằng câu hỏi này là cũ, nhưng vì tôi đang tìm kiếm câu trả lời, tôi nghĩ mình sẽ thêm câu trả lời cho bất kỳ ai khác.

Tuyên bố từ chối trách nhiệm đầy đủ: Dự án tôi đang đề cập là của riêng tôi, nhưng nó hoàn toàn miễn phí và là nguồn mở.

Tôi đã gặp phải sự cố rất giống nhau và đã kết thúc việc tự mình cuộn solution.Các mã kiểm tra sẽ trông như thế này:

from CLITest import CLITest, TestSuite 
from subprocess import CalledProcessError 


class TestEchoPrintsToScreen(CLITest): 
    '''Tests whether the string passed in is the string 
    passed out''' 

    def test_output_contains_input(self): 
     self.assertNotIsInstance(self.output, CalledProcessError) 
     self.assertIn("test", self.output) 

    def test_ouput_equals_input(self): 
     self.assertNotIsInstance(self.output, CalledProcessError) 
     self.assertEqual("test", self.output) 

suite = TestSuite() 

suite.add_test(TestEchoPrintsToScreen("echo test")) 

suite.run_tests() 

này làm việc tốt, đủ để làm cho tôi thông qua các vấn đề của tôi, nhưng tôi biết nó có thể sử dụng một số công việc nhiều hơn để làm cho nó mạnh mẽ như có thể (suối khám phá thử nghiệm để ghi nhớ). Nó có thể giúp, và tôi luôn yêu một yêu cầu kéo tốt.

Các vấn đề liên quan