factory_boy & behave

a talk on factory_boy and behave at Belfast Python Jan 2016

Transcript

1. FA C T O RY _ B O Y &
   B E H AV E
   S T E P H E N M C C U L L O U G H / / @ S W M C C / / P Y B E L FA S T / / J A N 2 0 1 6
   

   View Slide

2. A B O U T M E
   • @swmcc on the interwebs
   • Currently working at Shopkeep
   • Talk was written when I was working at MissionIQ
   

   View Slide

3. T H E V I R T U E O F T E S T I N G ?
   A L L A B O U T T E S T I N G
   

   View Slide

4. – S O M E O N E I U S E D T O W O R K F O R
   “I can’t sell tests, Stephen!”
   

   View Slide

5. W H AT I TA L K
   A B O U T
   • factory_boy - is a fixtures
   replacement based tool
   • behave - uses tests written
   in a natural language style,
   backed up by Python code
   

   View Slide

6. FA C T O RY _ B O Y
   

   View Slide

7. A U D I T P L U S
   • Mission IQ - auditplus.
   • ipad app + web ‘back-end’
   

   View Slide

8. A U D I T P L U S
   • Built using django.
   • First developed in May 2014 as a MVP.
   • Fully tested from the start.
   • Positive feedback lead to it becoming a full product.
   

   View Slide

9. W H Y U S E FA C T O RY _ B O Y ?
   • Audit didn’t use factory_boy from the start.
   • Happily used fixtures for over a year.
   

   View Slide

10. W H AT I S W R O N G W I T H F I X T U R E S ?
    • Easy to create. ‘manage.py dumpdata’.
    • Hard to read.
    • Hard to update.
    • Signal gets lost in the noise over time.
    

    View Slide

11. W H Y WA S A U D I T F E E L I N G T H E PA I N ?
    • The more complex the business logic the more
    complex the setup for a test case.
    

    View Slide

12. W H Y WA S A U D I T F E E L I N G T H E PA I N ?
    • Institutional knowledge required to write tests.
    • Fixture file was getting too big and a pain to edit.
    • Tests were getting slow to run.
    • Tests were getting too much of a pain to write.
    

    View Slide

13. I N T R O T O FA C T O RY _ B O Y
    • What it looks like in the wild
    

    View Slide

14. FA C T O RY _ B O Y
    • Can return default information.
    • Can override parameters if needed.
    • ‘Helper fields’ to aid in creating dynamic data.
    • This leads to a very potent testing framework.
    

    View Slide

15. S E Q U E N C E AT T R I B U T E S
    

    View Slide

16. L A Z Y AT T R I B U T E S
    

    View Slide

17. S C A F F O L D I N G
    

    View Slide

18. N I C E F E AT U R E S
    • traverse joins - using django ‘__’ syntax. 

    

    user = UserFactory(profile__wants_sms_reminders=False,
    • don’t save to the database.

    

    F.build()
    • default attribute as a dictionary.

    

    F.attributes()
    • override creation process.

    

    def create(self, **kwargs):

    

    View Slide

19. O R M S U P P O R T
    • Django
    • SQLAlchemy
    • Mogo
    • MogoMachine
    

    View Slide

20. B E H AV E
    

    View Slide

21. W H AT I S B E H AV E ?
    • behave is behaviour-driven development, Python style
    

    View Slide

22. – D A N N O R T H
    “BDD is a second-generation, outside–in, pull-
    based, multiple-stakeholder, multiple-scale, high-
    automation, agile methodology. It describes a
    cycle of interactions with well-defined outputs,
    resulting in the delivery of working, tested software
    that matters.”
    

    View Slide

23. – B E N N O R I C E
    “Behaviour testing allows you to test your
    application as a whole in such a way that all
    stakeholders can define and understand what is
    being tested.”
    

    View Slide

24. B D D ?
    • All stake holders (people that define, write and own
    the requirements) can understand what is being
    tested.
    • Much bigger avenue of agreement during the process.
    • Encourages thinking about the application in a natural,
    consistent language.
    

    View Slide

25. A L L O W E V E RY B O D Y T O W R I T E T E S T S
    • This is the ‘happy path’.
    • I have yet to see it happen.
    • I don’t think its necessarily a good thing to allow this.
    

    View Slide

26. R E Q U I R E M E N T S
    • Don’t define your tests from your requirements.
    • Then don’t define your application from your
    requirements.
    • You ‘just’ define your application from the tests.
    • And then tests ARE the requirements!
    

    View Slide

27. F E AT U R E S
    • As an [actor] (person/api consumer)
    • In order to [gain some benefit]
    • I want [a feature]
    

    View Slide

28. S C E N A R I O S
    • Given [a precondition]
    • When [an action]
    • Then [an expected outcome]
    

    View Slide

29. E X A M P L E O F A F E AT U R E
    

    View Slide

30. B I N D I N G
    • A ‘feature’ has to be binded to ‘something’ that can
    test it.
    

    View Slide

31. E X A M P L E O F A S T E P
    

    View Slide

32. G O O D A N D T H E B A D
    • As a concept I think BDD is good if in concert with
    other practises.
    • Everyone writing tests is a pipe dream.
    • The tooling is awful but if you keep your tests stupid it
    makes it easier.
    

    View Slide

33. View Slide