Java Reference
In-Depth Information
their overly documentation-centric focus (writing documents for the sake of documents), and their bloated
format, use cases have fallen out of favor and been replaced with user stories in agile development.
User stories mark the beginning of the development cycle. Let's continue by looking at a few of the
other tools used over the rest of the cycle.
Capturing Design with Test-Driven Development
Test-driven development (TDD) is another agile practice. When using TDD, a developer first writes a test
that fails and then implements the code to make the test pass. Designed to require that developers think
about what they're trying to code before they code it, TDD (also called test-first development) has been
proven to make developers more productive, use their debuggers less, and end up with cleaner code.
Another advantage of TDD is that tests serve as executable documentation. Unlike user stories or
other forms of documentation that become stale due to lack of maintenance, automated tests are always
updated as part of the ongoing maintenance of the code. If you want to understand how a piece of code
is intended to work, you can look at the unit tests for a complete picture of the scenarios in which the
developers intended their code to be used.
Although TDD has a number of positives, you won't use it much in this topic. It's a great tool for
development, but it isn't the best for explaining how things work. However, Chapter 12 looks at testing of
all types, from unit testing to functional testing, using open source tools including JUnit, Mockito, and
the testing additions in Spring.
Using a Source-Control System
In Chapter 2, you took a quick peek at source control when you used Git to retrieve the source code for
Spring Batch. Although it isn't a requirement by any means, you're strongly encouraged to use a source-
control system for all your development. Whether you choose to set up a central Subversion repository
or use Git locally, the features that source control provides are essential for productive programming.
You're probably thinking, “Why would I use source control for code that I'm going to throw away
while I'm learning?” That is the strongest reason I can think of to use it. By using a version-control
system, you give yourself a safety net to try things. Commit your working code; try something that may
not work. If it does, commit the new revision. If not, roll back to the previous revision with no harm
done. Think about the last time you learned a new technology and did so without version control. I'm
sure there were times when you coded your way down a path that didn't pan out and were then stuck to
debug your way out of it because you didn't have a previously working copy. Save yourself the headache
and allow yourself to make mistakes in a controlled environment by using version control.
Working with a True Development Environment
There are many other pieces to development in an agile environment. Get yourself a good IDE. Because
this topic is purposely written to be IDE agnostic, it won't go into pros and cons of each. However, be
sure you have a good one, and learn it well, including the keyboard shortcuts.
Although spending a lot of time setting up a continuous integration environment may not make
sense for you while you learn a given technology, it may be worth setting one up to use in general for
your personal development. You never know when that widget you're developing on the side will be the
next big thing, and you'd hate to have to go back and set up source control and continuous integration,
etc when things are starting to get exciting. A few good continuous integration systems are available for
free, but I strongly recommend Hudson (or its brother Jenkins). Both of them are easy to use and highly
extendable, so you can configure all kinds of additional functionality including things like integrating
with Sonar and other code-analysis tools and executing automated functional tests.
