Another test speedified

6 views
Skip to first unread message

Jo Paulger

unread,
Jun 12, 2013, 9:33:06 AM6/12/13
to econsens...@googlegroups.com, Mark Skipper
Hi all,

Just merged in a lovely new unit test from Philip (thanks Philip!), and thought that while I was in the file I may as well spend a couple of minutes converting it from an old-style-client-and-fixture based slow test to a speedier test using our brand new (and still developing) guidelines for writing faster tests (thanks to Sarah). Hopefully this will provide a nice straightforward example of what we're aiming for.

A discussion attempting to define these guidelines can be found at https://github.com/aptivate/econsensus/pull/130. Hopefully we can formalise this somewhat at some point and maybe include it as a doc in the codebase.

View the commit to see the changes, and my explanation for each change I made.

This commit sped this one test up from 1.097 seconds to 0.319 seconds, which may not sound like much but scale that up to 160 tests (and more being added all the time) and it would represent a significant speed up over the entire test suite if we were to convert all or most of the tests we have. I can easily make a round of tea while it's running at the moment ... I'd rather my tea drinking were not dictated by the test suite ;D

I propose that for the time being, we try to ensure that new tests conform to these guidelines wherever possible (sometimes you'll need to use the test client for some reason, but I can't see any genuine reason for needing the fixtures). If we also continue to convert old tests as and when we're working on them anyway, then we'll gradually reduce the time it takes to run the suite (which would be great!). One day maybe one of us will have time to systematically go through and convert blocks of tests as well which should give more dramatic results. 

Please feel free to ask questions or suggest more improvements.

Cheers!

Jo

Sarah Bird

unread,
Jun 12, 2013, 10:15:25 AM6/12/13
to econsens...@googlegroups.com, Mark Skipper
Lovely :D

A small useful thing to know about factoryboy (so if you don't need to save it to the database, you don't have to :D - many things you do need to, not a ciritque of the test, just a nugget of information)

You can use the Factory class as a shortcut for the default build strategy:


user = UserFactory() # Same as UserFactory.create()

# Returns a User instance that's not saved
user = UserFactory.build()

# Returns a saved User instance
user = UserFactory.create()



--
You received this message because you are subscribed to the Google Groups "econsensusdiscuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to econsensusdisc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Sarah Bird
sa...@aptivate.org
skype: birdsarah

Sarah Bird

unread,
Jun 12, 2013, 10:16:45 AM6/12/13
to econsens...@googlegroups.com, Mark Skipper
Also as Mark Skipper mentioned in tech forum yesterday, you can always specify any variables you want, or override the defaults you put in the factory:


# Build a User instance and override first_name
>>> user = UserFactory.build(first_name='Joe')
>>> user.first_name
"Joe"

I'll stop cutting and pasting from the docs now :D - https://factoryboy.readthedocs.org/en/latest/

Jo Paulger

unread,
Jun 12, 2013, 10:56:28 AM6/12/13
to econsens...@googlegroups.com, Mark Skipper
Aha, good point. I always forget to consider .build(). Thanks!

Reply all
Reply to author
Forward
0 new messages