Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Testing: Appetite Comes With Eating

DZone's Guide to

Testing: Appetite Comes With Eating

The more you write tests and write testable code, the more important testing becomes, and the more you want to test.

· DevOps Zone
Free Resource

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

I’ve written a lot about testing. Some tips on integration tests, some how-tos, some general opinions about tests. But I haven’t told my “personal story” about testing.

Why are tests needed should be obvious by now. It’s not all about finding bugs (because then you can use an excuse like “QAs will find them anyway”), it’s about having a codebase that can remain stable with changes. And it’s about writing better code, because testable code is cleaner.

I didn’t always write tests. Well, at least not the right amount. I had read a lot about testing, about the benefits of testing, about test-first / test-driven, about test coverage. And it seemed somewhat distant. The CRUD-like business logic seemed unworthy of testing. A few if-statements here, a few database queries there, what’s to be tested?

There are companies where tests were “desirable”, “optional”, “good, but maybe not now”. There are times when marking a test with @Ignore looks ok. And although that always bites you in the end, you can’t get yourself motivated to get your coverage up.

Yup, I’ve been there. I’ve written tests “every now and then”, and knew how to tests, but it wasn’t my “nature”. But I’m “clean” now — not only at work, but also in side-projects, I think I have a somehow different mentality — “how do I test that” and “how do I write that in order to be able to test it”.

I won’t go into the discussion of whether “test-first” is better. I don’t do it — I’ve done it, but I don’t find it that important, provided you have the right mindset towards your code. The fact that you write your tests after the code doesn’t mean the code isn’t written with the tests in mind.

How did that happen? I didn’t have a failed project because of lack of tests, and I didn’t go on a soul-searching trip to find out that I have to write tests to achieve inner peace. I think it’s a combination of several factors.

First, it’s the company/team culture. The team that I’m in now has the right practical approach to tests – it doesn’t have to be 100% coverage, but it has to cover all edge cases — we even have a task in most stories that makes us explicitly think of any possible edge cases. Even if you want to write test, if nobody around is, then you get demotivated. But when everyone around is doing it, it becomes a habit.

Then there’s experience. After years of years of reading about the benefits and seeing the problems of not having tests, and seeing that even your mere 25% of coverage has given you some freedom and that the tested pieces just look better, one should eventually do it. It’s the way of things.

And finally, it’s about what the French express as “appetite comes with eating”. The more you write tests, the more you want to write them.

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:
testing

Published at DZone with permission of Bozhidar Bozhanov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

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

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}