Testing in Django

also, how to solve the problems that comes with a big codebase

Transcript

1. TESTING IN DJANGO (also, how to solve the problems that comes with a big codebase)
2. WHAT WE WILL SEE: * Unit and functional tests * Organizing your Django test codebase * 5 key ingredients for making testing a solution instead of a problem * Achieving fluency * How mocking works * Good tests require good code
3. UNIT AND FUNCTIONAL
4. UNIT TESTS •Are “unplugged”: should not make I/O at all, or make the least possible •Hard to write if you are testing existing code that is coupled, macaroni •Reasonably easy to write if you are testing existing code that is already decoupled •Easy to write if you writing code from scratch with TDD •Here is were you might use mocks most part of the time
5. UNIT TESTS Are fast because they don’t do I/O
6. UNIT TESTS Hard to write if you are testing existing code that is coupled, macaroni
7. UNIT TESTS Reasonably easy to write if you are testing existing code that is already decoupled
8. UNIT TESTS Just follow the 3 laws of TDD •You are not allowed to write any production code unless it is to make a failing unit test pass. •You are not allowed to write any more of a unit test than is sufficient to fail; and runtime errors are failures. •You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Uncle Bob Martin, 2005 Easy to write if you writing code from scratch with TDD
9. UNIT TESTS Here is were you might use mocks most part of the time
10. UNIT TESTS Here is were you might use mocks most part of the time
11. FUNCTIONAL TESTS •Test the entire thing •I/O is allowed, but not to outreach 3rd party resources •Slow •Still shouldn’t depend on 3rd party resources •Most part of the time you don’t need mocks •Unless you need to isolate 3rd party resources •Intense database usage
12. FUNCTIONAL TESTS Isolation! Isolation! Isolation!
13. ORGANIZING YOUR TEST CODEBASE
14. ORGANIZING YOUR TEST CODEBASE Nose: “If it looks like a test, it’s a test” Unclebob: “the faster ones first, slow ones last”
15. ORGANIZING YOUR TEST CODEBASE Unclebob! pip install unclebob
16. ORGANIZING YOUR TEST CODEBASE {appname}/tests/__init__.py {appname}/tests/unit/__init__.py {appname}/tests/unit/test_name.py {appname}/tests/functional/__init__.py {appname}/tests/functional/test_views.py Nose finds every python file name that starting with “test”
17. ORGANIZING YOUR TEST CODEBASE def test_functions_start_with_test(): (u”Single-line doctstrings provide ” “a much better feedback”) assert True, “:)” Any module-level functions that begin with “test” is called with no parameters by Nose
18. ORGANIZING YOUR TEST CODEBASE class TestClasses(object): def test_have_methods_starting_with_test(self): (u”Single-line doctstrings provide ” “a much better feedback”) assert True, “:)” Any module-level classes that begin with “Test” is instantiated by nose, then all the methods containing with “test” will be found and run
19. ORGANIZING YOUR TEST CODEBASE $ nosetests --verbosity=2 Single-line doctstrings provide a much better feedback ... ok -------------------------------------------------------------- Ran 1 test in 0.001s
20. 5 KEY INGREDIENTS that will make your tests taste good!
21. GOOD ASSERTION MESSAGES What differed? Oh gosh, I gotta drop a pdb in code
22. GOOD ASSERTION MESSAGES It’s better, but I had to write the message by myself the test suite will become repetitive overtime
23. GOOD ASSERTION MESSAGES This was a huge dictionary comparison, but it shows what exacly is the problem: the second deal is missing the twitter url
24. FLUENCY ON WRITING Setup Entry point Assertion
25. MOCK WHEN NECESSARY
26. MOCK WHEN NECESSARY
27. OPTIMIZE THE CODE FOR TESTABILITY Look at this guy
28. DEAL WITH GOOD CODE
29. DEAL WITH GOOD CODE
30. DEAL WITH GOOD CODE Okay
31. DEAL WITH GOOD CODE
32. SURE: WRITE FLUENT ASSERTIONS pip install sure
33. SURE: WRITE FLUENT ASSERTIONS A collection of assertions ready to use It provides meaningful and clear error messages
34. SURE: WRITE FLUENT ASSERTIONS Two APIs: assert that(source).equals(destination) source.should.be.equal(destination) or assert source.should.be.equal(destination) Old one: New one:
35. SURE: WRITE FLUENT ASSERTIONS Two APIs: assert that(source).equals(destination) source.should.be.equal(destination) or assert source.should.be.equal(destination) Old one: New one: Only available for CPython
36. SURE: WRITE FLUENT ASSERTIONS
37. SURE: WRITE FLUENT ASSERTIONS Equality assert source == destination, ( u”%r != %r” % (source, destination)) assert that(source).equals(destination) Old school: Sure: source.should.be.equal(destination) or
38. SURE: WRITE FLUENT ASSERTIONS Length assert len(source) is 5, ( u”%r should have 5 items but has %d” % (source, len(source))) assert that(source).len_is(5) Old school: Sure: source.should.have.length_of(5) or
39. SURE: WRITE FLUENT ASSERTIONS Exceptions def get_deal_by_id(id): return Deal.objects.get(id=id) Code: try: get_deal_by_id(5) raise AssertionError(“calling get_deal_by_id(5) “ ”should have raised but didn’t”) except Deal.DoesNotExist, e: assert unicode(e) == “Deal with id 5 does not exist”, ... Old school:
40. SURE: WRITE FLUENT ASSERTIONS Exceptions def get_deal_by_id(id): return Deal.objects.get(id=id) Code: assert that(get_deal_by_id, with_args=(5,)).raises(Deal.DoesNotExist) Sure: get_deal_by_id.when.called_with(5).should.throw( Deal.DoesNotExist, "Deal with id 5 does not exist", ) or
41. MOCK pip install mock ISOLATE CODE, SPY CALLS AND FAKE BEHAVIOR OF CALLABLES
42. MOCK - RETURN VALUES
43. MOCK - SIDE EFFECT
44. MOCK - SIDE EFFECT
45. MOCK - ALWAYS RETURNS MOCKS >>> from mock import Mock >>> request = Mock() >>> request.user.is_authenticated.return_value = False >>> >>> print request <Mock id='4297658320'> >>> print request.user <Mock name='mock.user' id='4297609680'> >>> print request.user.is_authenticated <Mock name='mock.user.is_authenticated' id='4297658256'> >>> >>> print request.user.is_authenticated() False
46. MOCK - SOME FACTS •If you are using too many mocks and your test becomes hard to undersdand: isolate your code •If it's too hard to setup your test, your production code is doing too much, isolate it! •In the end of the day, if still can't mock your code you have to do refactoring!
47. MOCK - SOME FACTS •If you are using too many mocks and your test becomes hard to undersdand: isolate your code •If it's too hard to setup your test, your production code is doing too much, isolate it! •In the end of the day, if still can't mock your code you have to do refactoring!
48. SOME OTHER INTERESTING THINGS
49. SOME OTHER INTERESTING THINGS Django test client + lxml or PyQuery You call urls with: import sure from django.test.client import Client from lxml import html http = Client() dom = html.fromstring(http.get(“/deals/ny.html”).content) dom.cssselect(“section.deal”).should.have.length_of(100)
50. SOME OTHER INTERESTING THINGS Django test client + lxml or PyQuery You call urls with: import sure from django.test.client import Client from pyquery import PyQuery http = Client() dom = PyQuery(http.get(“/deals/ny.html”).content) dom.find(“section.deal”).should.have.length_of(100)
51. SOME OTHER INTERESTING THINGS Splinter from splinter.browser import Browser browser = Browser() # Visit URL url = "http://www.google.com" browser.visit(url) browser.fill('q', 'splinter - python acceptance testing for web applications') # Find and click the 'search' button button = browser.find_by_name('btnG') # Interact with elements button.click() if browser.is_text_present('splinter.cobrateam.info'): print "Yes, the official website was found!" else: print "No, it wasn't found... We need to improve our SEO techniques"
52. SOME OTHER INTERESTING THINGS Lettuce for acceptance testing
53. Gabriel Falcão http://falcao.it @gabrielfalcao github.com/gabrielfalcao speakerdeck.com/u/gabrielfalcao Questions? Sure: http://falcao.it/sure Unclebob: http://falcao.it/unclebob
54. THANK YOU!