Upgrade to Pro — share decks privately, control downloads, hide ads and more …

factory_boy & behave

factory_boy & behave

a talk on factory_boy and behave at Belfast Python Jan 2016

Stephen McCullough

January 20, 2016
Tweet

More Decks by Stephen McCullough

Other Decks in Programming

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