Testing and the Single Responsibility Principle
Testing and the Single Responsibility Principle
Join the DZone community and get the full member experience.
Join For FreeVerify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!
Automated testing is hard! Therefore, if you're about to learn it, just keep going. Resist the initial learning curve as afterwards it'll allow you to adopt a completely different programming style. A common problem I've observed is that (mainly) "testing newbies" tend to create huge, bloated tests cases which quickly start to get unmanageable. Usually this discourages them and they abandon their tests. So what's the key?
When you start with automated (unit) testing, you usually apply a test-after approach. That's natural. While I think you should jump into testing in a test-first manner immediately, you will naturally end up doing test-after and then eventually slowly move back to real test-first. This test-after approach however is what lets you create big huge test cases normally as it is extremely difficult to focus on the single test cases.
An Example
Maintainability is one important aspect of creating successful tests, however, also feedback is extremely important. When you create automated tests, what you want to achieve in the end is to build a system that will notify you about any problems as early as possible: you increase the feedback loop, basically. Instead waiting for some human tester to provide you feedback in the form of a bug report, you let the automated test case give you that feedback while coding and adding new stuff.
For example:[TestMethod]
public void ShouldReturnCleanedConnectionStringAndSchemaTranslations()
{
//snip snip snip
Assert.AreEqual(cleanConnString, result);
Assert.AreEqual(1, schemaTranslations.Count(), "There should be 1 schema translation");
}
When this test fails, do you know what went wrong?? Yes, you have to open the details of the test failure and see which assert failed. But wouldn't it be better to split them (you see the "AND" in the test name) and create two, like
[TestMethod]
public void ShouldReturnCleanedConnectionString()
{
//snip snip snip
Assert.AreEqual(cleanConnString, result);}
}
[TestMethod]
public void ShouldReturnSchemaTranslations()
{
//snip snip snip
Assert.AreEqual(1, schemaTranslations.Count(), "There should be 1 schema translation");
}
Now when one of those two tests fails you immediately see which kind of code is probably broken, right?This kind of approach has several advantages. You now even optimized the provided feedback in that - in the best case - you don't have to even open the details and start to debug in order to understand what broke your test. Moreover when you refactor your code you have to touch less tests. Remember, small tests tend to break less often than large, big fat test methods. And finally, small tests are much easier to understand, fix, adapt etc...
Naming Conventions May Help
Good naming may actually help you identify tests with multiple responsibilities. These worked well for me:
- GivenSomethingIsTrueThenItShouldReturnSomeSpecificResult
- ShouldReturnSomeSpecificResult
Already when formulating the test name you quite quickly see any multiple expectations. What do you think?
Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.
Like This Article? Read More From DZone
Published at DZone with permission of Juri Strumpflohner . See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}