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

Doing More of What We Love

DZone's Guide to

Doing More of What We Love

Taking a TDD approach and developing the unit test first saves time and gets you back to the code quicker. Test twice, code once.

· Performance Zone ·
Free Resource

Maintain Application Performance with real-time monitoring and instrumentation for any application. Learn More!

Developers love writing code. It’s what we’re good at. It’s what we do.

But all sorts of things get in our way: Meetings. Reading and interpreting specifications. And the worst time-sink of all—debugging. Most of us would rather do anything other than debugging, but that’s where we end up spending a lot of our time.

Doing test-first development isn’t debugging, it’s writing code.

It replaces the need for extensive internal documentation because it exercises the system the way it will be used. It concretizes abstract requirements by forcing developers to create examples for the behavior they want to build through the act of writing tests.

This is equivalent to creating a rough sketch of what you want to build before you build it. Test-first development helps keep you on track and lets you know when you’re done building a feature. And knowing when to stop building a feature is important. We tend to overbuild not because we like overbuilding, but because we’re scared that that feature might be used in the field in ways we hadn’t anticipated, so we tend to overbuild to compensate.

Having a test that embodies the service we want to create, how we want to call it, and what we expect back, is equivalent to aiming a rifle before you fire it. Knowing your criteria for completion before you start is a good habit to get into.

All this is embodied in the unit test we write before we write the production code. Tests are the concretization of abstract requirements so they’re easier to understand and work with. Writing the test first isn’t busy work, it helps us nail down the behaviors we want to create and think about them apart from their implementation. This is central to properly encapsulating a system so it’s modular, verifiable, and extensible.

Writing the test first forces us to think of the services we write from our caller’s perspective. This also helps simplify the system. When we write the test first it guarantees that the code we write to make that test pass will be testable. It must be, by definition, so this means we’re always writing testable code.

Too often I see developers write their code first only to find that trying to write a unit test for the existing code is so hard they usually have to rewrite the code to make it more testable. If you write the test first then you never have this problem.

Doing TDD is writing code: test code and production code. We spend less time on written requirements and debugging and more time on what we love doing most: writing code.

Collect, analyze, and visualize performance data from mobile to mainframe with AutoPilot APM. Learn More!

Topics:
performance ,Tdd ,unit testing ,efficiency

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}