chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male

How To Improve Your Tests

This Wednesday we’re running a webinar on the top 5 questions asked in unit testing. And, hopefully, we’ll have some answers Smile We’ve done some groundwork, asking people what they are interested in, and for experienced people- what do they get asked.

The results were very interesting. And you get to find out in the webinar.

Here’s a teaser: One of the most asked questions I’m going to cover is: How can I improve my tests?

This question is usually asked by people with a few test suites under their belts. They want to get more from their tests. So here are a few pointers:

  • Naming. The most important thing about a test is that it tests the right thing. The second is its name. It’s the first thing you see when something goes wrong. It should tell you the most about what’s gone wrong, so you can get from “found a bug” to “fix a bug”. Good names are descriptive, and make it possible to differentiate between tests and their siblings. You want to know if the test fails, but its brothers don’t. And you want to know that by name.
  • Reviewing. How do you know if the name you have for a test works? Grab someone (literally) and make him or her review it. While you’re at it, review the whole test. And the production code. And if possible, pair for the remainder  of the task. I guarantee you’ll get better readable code this way.
  • Test organization. Don’t fret about it. Just separate the quick from the slow (hopefully, you’re using Isolator to do that for you). And please don’t apply OO principles to test code.
  • Robustness. Tests are coupled to code. How much depends on you, and your toolset. For example, Isolator by default fakes methods regardless of the runtime arguments they are passed. Less specification means your tests will not break when something changes in the production code, for example, your change what’s passed for them. Another example, is to test public methods only. (There’s a caveat for that, and if you want to know, or just fight about it, come to the webinar).

That’s just the tip of the iceberg. Want to know more? Ask more questions?

Join me. Register here.