

How to start unit testing in a testless environment? - Justsignedup

Hey everyone, I am currently on a team without any good unit testing framework (crazy, i know). So the question is how to get people doing it.<p>Now, there is a desire from everyone to do it, but the friction seems to high. So I am looking to lessen the friction. We use Java, but languages like Groovy seem good as well.<p>Primary questions: Where to start testing? What is the best part of the system to attack usually to get the most traction or benefit.
======
niutski
My team was in the same situation as you about 2 years ago. We started writing
tests for bugs that were reported by customers, as those were the "hot-spots"
for regression. As we became more confident and adept at using JUnit, we
started writing tests for new features too. Only after 6 months did we start
looking at places in the code that were not covered by unit tests and started
filling them in to avoid regression. It was a lengthy process to get our
coverage to a decent level, but it was definitely worth the struggle.

------
darbelo
The easiest place to start testing is likely to be in the code you are
touching now. It is fresh in your head, you know what it does. Write a test
for that, it shouldn't take you too long.

If you are doing a targeted bugfix (i.e. not with a shotgun) you already know
the test you have to write: a test for the bug. Try to first write the test
and then make it pass (also know as fixing the bug), so you know that the test
will spot a regression on future runs.

If you are working on a new feature, try to isolate the core logic of the
feature and test that. If you can, test it in isolation from the rest of the
system and integrate it after you have achieved some semblance of correctness.

If your code base has parts that you only touch rarely and you know (or hope)
are reasonably solid, leave them for later. The highest risk for breakage
tends to be near the spots with the most code churn, so put your tests there.

Also remember that tests are code and they must be maintained as you would
maintain the rest of your code. Writing tests for implementation details that
have no real impact on program correctness won't yield you much value when
weighted against the cost of their maintenance.

If you are after the most "value per test" think about it this way: The most
valuable test you can write today is the one that will catch breakage
tomorrow. So, think of the code most likely to break (or the one that will
hurt you the most when it breaks) and test that. The first time that test
unexpectedly goes red, it will have paid for itself.

------
devrelm
It can be hard to work unit tests into legacy code. The first step might not
have to do anything with tests at all, but with refactoring/rearchitecting
your code to allow for proper unit tests. Without proper abstractions and
dependency injection, you'll find it hard to mock out your data access layer.

If you have a hard time convincing colleagues to go along with this, then
you'll just have to go ahead and start writing tests over top of a real
database (or whatever your data layer is.) They should see pretty quickly how
tedious it is to have to maintain a test db, and the benefits of being able to
mock it out.

In my opinion, one of the big concerns is isolating the business logic into
its own layer that is as loosely coupled to the data access and view layers as
possible. Data access and rendering errors are relatively easy to spot in
QA/UAT. The errors most likely to make it through black-box testing are
related to business logic, which can be dizzying in any app that's been around
long enough. It's important to distill the business logic into a single layer
where each business rule can be tested individually without the possibility of
interference from the view or data layers.

------
alexgaribay
Since you're using Java, why not start incorporating JUnit tests into your
packages? JUnit is simple enough to get started with and testing is fairly
straight forward. Most of the modern IDEs for Java support running JUnit
tests.

Good places to start adding tests would be wherever there is critical business
logic or areas of code that used very frequently. If you could spare the time,
try adding some tests everywhere. But if you can't, add tests to all new
functionality or areas that are being updated for bug fixes at the minimum.

Once you've got some tests in place, use a build system (i.e. Jenkins) and
have your units run every time there is a check-in to source control. Possibly
create some build tasks using Gradle and have your unit tests run at compile
time for Java.

------
logn
First you need a continuous integration server (which will run the tests and
builds). I recommend Jenkins. Then with a few settings on Jenkins you can
start running JUnit.

Then so as to not rock the boat too much, start by just writing tests for all
your own code. If that goes over ok, add tests for critical functions, such as
data operations or things like that.

You can print out coverage reports pretty easily with Emma.

[http://jenkins-ci.org/](http://jenkins-ci.org/)

[http://emma.sourceforge.net/](http://emma.sourceforge.net/)

------
vorg
> We use Java, but languages like Groovy seem good as well.

Because the Groovy project management at VMWare often slip references to
"Groovy" into some other query as part of their ongoing promotion efforts,
mentioning "but languages like Groovy seem good as well" without any direct
relevance to your primary question makes some of us suspicious. I'm mentioning
this just in case this is a genuine query.

~~~
Justsignedup
You know, thinking about it, it's not very relevant.

