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.
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.
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):
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.”
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.
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!
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.