Gateway JUG

Putting Your Technical Debt Under Control with Sonar

Companies fail all the time because they accumulate more debt than they can ever repay. Likewise,  software projects fail all them time when their technical debt gets out of control.

What is technical debt and how do you measure it?

Back in 1980, Meir Manny Lehman wrote that,

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it." 

Ward Cunnigham is a renowned developer who invented the wiki and a pioneer in Extreme Programming and design patterns. He expanded on Lehman's observation in a 1992 experience report:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."

(See this Wikipedia Technical Debt article for much more on the subject.)

So how do we measure technical debt?

There are plenty of tools and APIs that help with this, but each tends to focus on a narrow part of the problem.  For instance, unit and other automated tests inform us our code is working in the areas covered by the tests. But what if we missed tests for some code? Code coverage tools like Cobertura tell us how much test coverage we have. Our IDEs usually offer some insights using code inspections to help spot bad coding practices; e.g. Flagging an empty catch block. We can also use code inspection tools like FindBugs to inform us of possible bugs.

Wouldn't it be nice if there was a tool that would would bring all of these technical debt measurements together in a consilidated view? There is. It's called Sonar.

Sonar is an LGPL licensed, open source platform hosted at Codehaus. It's what we can use to manage code quality to help us manage and reduce our technical debt. It covers the 7 axes of code quality:

 

This presentation shows how you can Sonar today to first measure, and then improve, code quality. In the presentation, I will cover

• Downloading and configuring Sonar
• The Sonar dashboard
• Code quality metrics covered
• Using The SQALE Ratings
• Alerts
• Hotspots
• Time Machine
• Cloud Views
• Design issues
• Timeline

All of these will be demonstrated with live demonstrations of this remarkable tool.

We need to know you're coming, so please be sure to RSVP using the link on the right sidebar.

Speaker: Jack Frosch

Sponsor: Modis

April 5th Meething - Collaborators, I Mock Thee!

Ok, I admit it. I really like automated testing.

In the beginning, they tell us that we're meeting the requirements, at least as well as we understand them.  Along the way, they validate that nontrivial code we are writing isn't hiding a bug that will surely be found by a user at the most inopportune time.  Long after the code is created and committed, they allow us to test new features. Alas, when bugs do scurry out of the darkness into the light of our user's monitor, automated tests help us verify the bug and its fix. Most importantly, they give us the confidence to refactor code to make it better. (It's axiomatic that the first edition of code written under a tight schedule can be improved upon!)

Not all tests are equal though.

Automated functional (i.e. web) testing tends to be tedious to write and is a little fragile in a changing business environment. Of course, starting and restarting a server drains our development momentum.

Integration tests are a bit better, but still impose time-wasting server starts, Spring context loading, database preparation, etc.

Pure unit tests are a different matter altogether.

Clean and fast, they tell us right away (in under 50ms) that the thing we're testing is doing what we think it should do. No servers to start up. No Spring context to load. We're in and out after just a few minutes of test code writing and 50ms of test execution.

One testing reality we have to deal with is that classes under test usually have collaborators. We're lucky if the collaborators are even available as they are often under parallel development. If they are, maybe they're being looked up (i.e. via JNDI) or, in the worst case, are being instantiated in the middle of a method we're testing. Our class under test relies on the collaborator's behavior and resulting data so the collaborators have to be accounted for by our test. Unaware of other options, we might just give in and make our speedy unit tests into slow integration tests to give us access to the collaborators.

But we do have other options.

This presentation is all about keeping unit tests pure unit tests.

First, we'll discuss some general testing concepts and coding pitfalls that we can avoid to help us in our effort. We'll also discuss challenges when creating tests for existing code that's poorly written and difficult to test. Then we'll dive into using Mocks and Stubs, what they are, how to write them, and why you shouldn't write them. Instead, I'll show you three Java mocking frameworks you should consider, with emphasis on Mockito, one of the new kids on the block.  Throughout the presentation, I'll show you code that illustrates the concepts being discussed.  In summary, we'll cover:

• Overview of automated testing
• Creating tests for badly written code
• Coding pitfalls to avoid that also make testing easier
• Mocks and Stubs
• Using a mocking frameworks - a brief look at jMock and EasyMock
• Introduction to Mockito

Speaker: Jack Frosch

Sponsor: TransITions