How to start unit testing in a testless environment?
6 comments
> 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.
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.
You know, thinking about it, it's not very relevant.
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.
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.
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.
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.
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.
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.
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.
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://emma.sourceforge.net/
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://emma.sourceforge.net/
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.
Primary questions: Where to start testing? What is the best part of the system to attack usually to get the most traction or benefit.