Over a million developers have joined DZone.

Testing and the Single Responsibility Principle

· Java Zone

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

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:
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

public void ShouldReturnCleanedConnectionString()
    //snip snip snip
    Assert.AreEqual(cleanConnString, result);}
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?

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.


Published at DZone with permission of Juri Strumpflohner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}