2009-10-20 37 views
15

Tôi chủ yếu là một anh chàng Ruby, nhưng gần đây tôi đã làm việc trên rất nhiều công cụ Python, đặc biệt, mã App Engine. Trong Ruby, tôi sử dụng tích hợp liên tục tự động (autotest), công cụ bảo vệ mã (rcov), phân tích tĩnh (reek) và thử nghiệm đột biến (heckle) trong quá trình phát triển của mình, nhưng tôi không chắc chắn cách tốt nhất để thiết lập quá trình phát triển tương tự cho môi trường App Engine. Tôi cũng muốn quan tâm đến các chất tương tự với RSpecCucumber cho Python có thể hoạt động trong App Engine.Tôi làm cách nào để thiết lập quy trình phát triển TDD với Google App Engine?

+3

Thật tuyệt vời khi văn hóa TDD đã hình thành bên trong cộng đồng Ruby –

Trả lời

15

Mở dự án GAE của tôi, tôi sử dụng:

  • NoseGAE — Đây là phần quan trọng mà quan hệ tất cả phần còn lại cùng nhau
  • Giả lập, như trong câu trả lời tuyệt vời của John. Tôi sử dụng điều này phần lớn cho AWS và dịch vụ web khác
  • Lịch thi đấu (gói, không phải là ý tưởng)

Tôi cũng thích nhiều thành ngữ của Rails. Tôi đã phá vỡ các bài kiểm tra của tôi thành đơn vị, và chức năng sử dụng các gói Python. Bạn có thể chạy một tập hợp con các bài kiểm tra bằng cách sử dụng --tests=unit hoặc --tests=functional. Đó là tất cả một chút hướng dẫn sử dụng hơn Rails nhưng ít nhất tôi có thể đơn vị kiểm tra các công cụ cứng và chắc chắn rằng tôi không bao giờ có hồi quy.

Tôi cũng đã thực hiện một lớp đơn giản FunctionalTest để thực hiện nhiều hành động rất phổ biến trong Rails, chẳng hạn như assert_responseassert_xpath (tương tự như assert_select).

class FunctionalTest(Test): 
    def get(self, *args, **kw): 
    self.response = app.get(*args, **kw) 

    def post(self, *args, **kw): 
    self.response = app.post(*args, **kw) 

    def assert_response(self, expected): 
    pattern = str(expected) if re.search(r'^\d+$', expected) \ 
          else (r'^\d+ %s' % expected) 
    assert re.search(pattern, self.response.status, re.IGNORECASE), \ 
      'Response status was not "%s": %s' % (expected, self.response.status) 

    def assert_xpath(self, path, expected): 
    element = ElementTree.fromstring(self.response.body) 
    found_nodes = element.findall('.' + path) 
    if type(expected) is int: 
     assert_equal(expected, len(found_nodes)) 
    elif type(expected) is str or type(expected) is unicode: 
     assert (True in [(node.text == expected) for node in found_nodes]) 
    else: 
     raise Exception, "Unknown expected value: %r" % type(expected) 

Nếu bạn đang làm rất nhiều tìm kiếm bình đẳng ListElement, chắc chắn học cú pháp --tests=foo vì xét nghiệm cho phù hợp với các yếu tố trong một danh sách rất chậm.

Đôi khi tôi muốn tải bảng điều khiển Rails vào dữ liệu lịch thi đấu của mình để xem điều gì đang xảy ra trong môi trường thử nghiệm (ví dụ: script/console test). Để làm được điều gì đó tương tự với GAE, chạy dev_appserver.py với tham số --datastore_path="$TMPDIR/nosegae.datastore" (hoặc có thể thay thế cho /tmp$TMPDIR.

+0

Chấp nhận câu trả lời này cho bit thông tin quan trọng NoseGAE, mặc dù câu trả lời của John cũng cực kỳ hữu ích. –

+0

Cảm ơn, Bob! Thật vậy, tôi dự định sẽ tích hợp nhiều đề xuất của John vào các dự án của riêng tôi trong tương lai. – JasonSmith

+0

Bob, quay trở lại thông qua mã của tôi Tôi nhận thấy rằng tôi đã có một cách để chạy máy chủ SDK bình thường đối với các cửa hàng dữ liệu tạo ra NoseGAE, vì vậy tôi thêm rằng như là đoạn cuối cùng. – JasonSmith

26

Bạn sẽ không phải lúc nào cũng tìm thấy một trong những điểm tương đương của các công cụ kiểm tra Ruby trong Python, nhưng có một số công cụ kiểm tra tuyệt vời trong Python. Một số công cụ mà tôi thấy hữu ích bao gồm:

  • unittest - công cụ xUnit có trong thư viện chuẩn Python. Nó bao gồm tất cả các điều cơ bản để kiểm tra đơn vị.
  • doctest - một phần tuyệt vời của thư viện chuẩn, nó cho phép bạn viết các bài kiểm tra trong các tài liệu về hàm, lớp, mô-đun, phương pháp. Thật tuyệt vời khi chuyển tải mục đích sử dụng API. Ian Bicking đề xuất sử dụng doctest cho Phát triển theo hướng hành vi. Doctest phù hợp rất tốt với hệ thống tài liệu Sphinx (bạn có thể đảm bảo tất cả các ví dụ trong tài liệu của bạn đều được chuyển mỗi lần bạn tạo tài liệu).
  • nosepy.test được xem là phiên bản thế hệ tiếp theo của unittest. Họ có thể chạy tất cả các trường hợp không có sẵn hiện tại, nhưng cho phép các bài kiểm tra đơn vị không dựa trên lớp học dễ dàng hơn. py.test cũng cho phép thực thi phân tán.
  • mock là thư viện tốt cho hành vi nhạo báng.
  • tdaemon xem thư mục để cập nhật mã của bạn và sẽ thực thi lại bộ thử nghiệm của bạn. (số personal branch của tôi có một số cải tiến chưa được thêm).
  • Buildbot, Bitten và thậm chí Hudson tất cả hoạt động tốt như các máy chủ tích hợp liên tục chính thức cho mã Python.
  • coverage.py tính toán độ bao phủ mã của mã của bạn.
  • pylint sẽ cung cấp một phân tích giống như lint mã của bạn, đảm bảo mã tuân theo quy ước mã hóa phổ biến và không có bất kỳ lỗi phổ biến nào. Ngoài ra còn có một công cụ phân tích "nhẹ", PyFlakes.
  • Có một số công cụ kiểm tra HTTP/Trình duyệt hoạt động tốt trong Python, bao gồm Twill, SeleniumWindmill.

Nếu bạn đang sử dụng Django trên App Engine, nó bao gồm several extensions để hủy gửi cho phép bạn mô phỏng ứng dụng khách HTTP và cơ sở dữ liệu tồn tại.

Có rất nhiều công cụ khác mà tôi chưa sử dụng (chẳng hạn như PySpecBehaviour) cũng có thể hữu ích. Tôi đã không nhìn thấy bất kỳ công cụ thử nghiệm đột biến trong Python, nhưng tôi đặt cược có một trong đó (tôi rất thích tìm hiểu nó là gì).

Thử nghiệm vui vẻ!

+3

Chỉ ưu tiên câu hỏi này cho câu trả lời này –

+0

Rất nhiều liên kết tuyệt vời ở đây. Mặc dù vậy, đối với GAE, tôi muốn xem thêm câu trả lời chi tiết cách họ tích hợp mọi thứ với môi trường phát triển của GAE, đặc biệt với OS X trình khởi chạy. –

+1

Bob, câu trả lời của John thật tuyệt vời. Như tôi đã nói bên dưới, một khi bạn cài đặt plugin NoseGAE cho Mũi, nó khá mượt mà với tất cả các công cụ này. – JasonSmith

3

đã không được sử dụng App Engine, nhưng cảm giác của tôi cho công cụ kiểm tra python phổ biến nhất là

  • unittest/doctest là các gói thử nghiệm từ các tiêu chuẩn thư viện Python. unittest là xUnit cho python.
  • nose là trình kiểm tra/tìm kiếm thử nghiệm. Nó có nhiều tùy chọn, bao gồm --with-coverage, sử dụng coverage để cung cấp cho bạn mã bảo hiểm báo cáo.
  • pylint là trình kiểm tra lint nổi bật nhất cho trăn. Hữu ích vượt quá trình kiểm tra cú pháp vì nó khuyến cáo về các biến/chức năng không sử dụng, khi các phương thức phải là các hàm và hơn thế nữa.
  • pester (đột biến thử nghiệm)
  • buildbot (tích hợp liên tục)

Có thể bạn sẽ muốn tham khảo này (không hoàn toàn đầy đủ) danh sách các Python Testing Tools.

Đối với BDD, trường này là lần cuối cùng tôi đã kiểm tra. Nhiều công cụ BDD thực sự không thể sử dụng được bằng mũi và/hoặc quá giới hạn trong cú pháp mà chúng yêu cầu. Bạn có thể có một số may mắn với spec, là một plugin mũi giống BDD. Chỉ cần tìm thấy pyccuracy, trông rất giống dưa chuột, nhưng tôi chưa thử .

Đối với những gì giá trị của nó, bây giờ tôi chỉ cần sử dụng nosetests -v (Á hậu mũi với --verbose), mà sẽ sử dụng dòng đầu tiên của docstring trong runner thử nghiệm đầu ra. Đó là, cho một thử nghiệm như:

class TestFoo(unittest.TestCase): 
    def testAnyNameHere(self): 
     """ Foo should be bar""" 
     foo = "bar" 
     self.assertEqual(foo, 'bar') 

nosetests sẽ cung cấp cho:

$ nosetests -v 
Foo should be bar... ok 

----------------------------- 
Ran 1 tests in 0.002s 
OK 
+0

+1 cho pester đề cập đến –

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