Today, I had my long expected session with Avdi Grimm. It was great!
Forget everything you know, there is always a simpler way to do it!
It was all about improving testing, and his supervision was great. I am excited and encouraged. Basic truths with testing your code are very important it leads to better organized code and make pragmatical approaches even possible. But most important, it makes your life easier when you stick with some fundamental truths.
Is it about your code, or about the software you’re building? Or. The importance of High Level Testing
Don’t get lost in your code. Unit / Integration / Contrller / View Tests, so many words – so few things to consider.
What ever you can test with acceptance test, do it. Just use integration tests for slow things, database related things. Wherever you iterate over records to test special cases, you may wanna use integration tests. Otherwise, for example if you expect a link to be on a page, just test it by clicking the link. Don’t test if its there. A link-click / being on a page after a user action or whatever you expect from your application process, is most likely implicit enough.
Example: Don’t test validations in your highlevel test. Test the case of successfully filling out the form, and may be not successfully filling out the form.
Validations should be in the Integration Test, Application behavior in the Acceptance Test.
Don’t fake stuff from yourself. Nobody likes a fake.
Stubbing and mocking doing right?
Stub other Service Objects, this is fine, avoid stubbing and mocking internal methods and variables, use a specific context and initialize objects as they act in real world.
What you see, is what you get
We often test things, which doesn’t make a it more valuable, or give us more information. Its just noise.
Your tests are as good, as your sample data is. With good reliable test data, you just test the return value,
you most likely don’t care about internal behavior of a method, but about its end result.
So send the values in and test, if you get the expected results out; thats it.
Huhm!? – Wtf am I testing here?
Measure your quality of your test code by checking, how good you can read your tests. Can others understand, what your are actually doing?
Use simple and verbose english in your describe / context / specify / it blocks.
Testing seems not to be that compatible with the DRY principle. It doesn’t matter in this context. More important is documentation and maintainability in this scope Be verbose! As better you understand your tests, as more do others, who jump into your code eventually.
Is there something missing? How do you test? Please leave some comments.