I just had a great pairing session with mattyw on writing amulet tests, and
I picked up some things that really resonated with me by watching his
workflow during writing the tests.

To most of you this will be "python 101" but I thought since I'm missing
these key components during my workflow, it would be good to send a gentle
reminder that we all can and should be striving to put our best foot
forward when testing, and think about the non-engineers that are
undoubtedly going to be looking over our work.

When composing the tests, he created docstrings for each assertion test to
implicitly define what the tests were *supposed* to be doing.

"""
test_mongodb_credential_exchange  Validates the data being sent across the
wire is what we expect
"""

"""
test_mongodb_credential_connection With the sent credentials, validate we
can connect to the unit under test
"""

These are brilliant things to know, at a glance we have a solid
understanding of what the code is doing.


During his error messages, instead of throwing a generic response like "key
not found in relation: %s" % k - his messages were super descriptive :

amulet.raise_status(amulet.ERROR, msg="Credentials submit were invalid %s"
% key[k])

When looking at testing output, we'll have a better ability to grokk what
exactly went wrong in the output vs some random string that I as the
developer would be the only person that knows. As we move our CI infra
towards being the key component in our Juju story - this gives everyone the
ability to know whats broken when things go red.

Pretty simple stuff that I will be keeping in mind as I continue writing
bundle tests, and thought I would highlight something awesome a co-worker
was doing, and taught me a thing or two while doing it.

All the best,

Charles
-- 
Juju mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to