Untested code is
 broken code
         Martin Aspeli
  Philipp von Weitershausen
why tests?
I know I should write
      tests, but...

• they take time to write
• I’m a good developer
• my customer / the community ...
find the bug...
class Employee(object):
    def __init__(self, name, position, employee_no=None):
        self.name = name
...
find the bug...
class Employee(object):
    def __init__(self, name, position, employee_no=None):
        self.name = name
...
still asking why tests?

• you rarely catch problems like these with
  manual testing
• put the time you waste catching si...
tests for print_salary
Employee w/o an employee number is ignored:

  >>> print_salary(Employee('Adam', 'Developer'))
  Yo...
tests for bugs

• when people report bugs, you want to make
  sure you can reproduce them
• when you fix bugs, you want to ...
test that exercises the
       bug (it fails)
Employee w/o an employee number is ignored:

  >>> print_salary(Employee('Ad...
making the test pass
class Employee(object):
    def __init__(self, name, position, employee_no=None):
        self.name =...
test-driven development
         (TDD)
write tests first

• say what?
• I’m serious
 • you don’t “forget” to write tests
 • you can catch design mistakes early on
executable
documentation
tests and docs

• tests should exercise APIs, demonstrate how
  to use them
• developers may find documentation in tests
• ...
doctests

• look like interpreter session
• with text paragraphs in between
• reStructuredText
 • can be rendered to HTML,...
Interfaces are defined using Python class statements::

  >>> import zope.interface
  >>> class IFoo(zope.interface.Interf...
documentation-driven
    development
• write doctests first
• “science-fiction”
• tell a story to an imaginary user
• use “w...
Martin will now show
 some examples for
       Plone
Upcoming SlideShare
Loading in...5
×

Philipp Von Weitershausen Untested Code Is Broken Code

3,030

Published on

If you're one of those programmers who think that subtle bugs only happen to other people, or that only bad programmers need extensive testing, this talk is for you.

Any non-trivial piece of software should be accompanied by an appropriate suite of automated tests. Your Plone products are no exception. By understanding approaches to automated testing and following good working practices, you can improve the quality of your code, as well as your confidence in your own work.

In this talk, Philipp von Weitershausen and Martin Aspeli will take you through the theory and practice of unit testing, integration testing and functional testing. Through real-world examples, you will learn that testing is not only necessary: it can be fun too!

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,030
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
51
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Philipp Von Weitershausen Untested Code Is Broken Code"

  1. 1. Untested code is broken code Martin Aspeli Philipp von Weitershausen
  2. 2. why tests?
  3. 3. I know I should write tests, but... • they take time to write • I’m a good developer • my customer / the community does the testing
  4. 4. find the bug... class Employee(object): def __init__(self, name, position, employee_no=None): self.name = name self.position = position self.employee_no = employee_no salaries = {0: 12000, 1: 4000, 2: 8000, 3: 4000} def print_salary(employee): if employee.employee_no: salary = salaries.get(employee.employee_no, 0) print quot;You make EUR %s.quot; % salary else: print quot;You're not an employee currently.quot;
  5. 5. find the bug... class Employee(object): def __init__(self, name, position, employee_no=None): self.name = name self.position = position self.employee_no = employee_no salaries = {0: 12000, 1: 4000, 2: 8000, 3: 4000} def print_salary(employee): if employee.employee_no: salary = salaries.get(employee.employee_no, 0) print quot;You make EUR %s.quot; % salary else: print quot;You're not an employee currently.quot;
  6. 6. still asking why tests? • you rarely catch problems like these with manual testing • put the time you waste catching silly bugs, typos into writing tests • you end up saving lots of time when you refactor
  7. 7. tests for print_salary Employee w/o an employee number is ignored: >>> print_salary(Employee('Adam', 'Developer')) You're not an employee currently Employee w/o a known employee number earns nothing: >>> print_salary(Employee('Berta', 'Designer', 100)) You make EUR 0. Employee w/ a valid employee number is found properly: >>> print_salary(Employee('Chris', 'CTO', 2)) You make EUR 8000.
  8. 8. tests for bugs • when people report bugs, you want to make sure you can reproduce them • when you fix bugs, you want to make sure they stay fixed
  9. 9. test that exercises the bug (it fails) Employee w/o an employee number is ignored: >>> print_salary(Employee('Adam', 'Developer')) You're not an employee currently Employee w/o a known employee number earns nothing: >>> print_salary(Employee('Berta', 'Designer', 100)) You make EUR 0. Employee w/ a valid employee number is found properly: >>> print_salary(Employee('Chris', 'CTO', 2)) You make EUR 8000. Zero is a valid employee number: >>> print_salary(Employee('Devon', 'CEO', 0)) You make EUR 12000
  10. 10. making the test pass class Employee(object): def __init__(self, name, position, employee_no=None): self.name = name self.position = position self.employee_no = employee_no salaries = {0: 12000, 1: 4000, 2: 8000, 3: 4000} def print_salary(employee): if employee.employee_no is not None: salary = salaries.get(employee.employee_no, 0) print quot;You make EUR %s.quot; % salary else: print quot;You're not an employee currently.quot;
  11. 11. test-driven development (TDD)
  12. 12. write tests first • say what? • I’m serious • you don’t “forget” to write tests • you can catch design mistakes early on
  13. 13. executable documentation
  14. 14. tests and docs • tests should exercise APIs, demonstrate how to use them • developers may find documentation in tests • why not turn them into proper documentation?
  15. 15. doctests • look like interpreter session • with text paragraphs in between • reStructuredText • can be rendered to HTML, PDF, etc.
  16. 16. Interfaces are defined using Python class statements:: >>> import zope.interface >>> class IFoo(zope.interface.Interface): ... quot;quot;quot;Foo blah blahquot;quot;quot; ... ... x = zope.interface.Attribute(quot;quot;quot;X blah blahquot;quot;quot;) ... ... def bar(q, r=None): ... quot;quot;quot;bar blah blahquot;quot;quot; In the example above, we've created an interface:: >>> type(IFoo) <class 'zope.interface.interface.InterfaceClass'> We can ask for the interface's documentation:: >>> IFoo.__doc__ 'Foo blah blah'
  17. 17. documentation-driven development • write doctests first • “science-fiction” • tell a story to an imaginary user • use “we” and “you” • put the story on the product homepage (e.g. plone.org, PyPI)
  18. 18. Martin will now show some examples for Plone
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×