Testing Times Part I: How do team introduce automated testing?

Test-driven and test first development have become very fashionable over the past few years. Ensuring code has tests is one of the core Extreme Programming rules, but it can also be one of the most difficult to introduce to a team. Although the principles are very straight forward, many teams have great difficulty adapting to an automated testing approach. Some of these teams don’t have any existing testing strategies in place, meaning that incorporating automated testing into development seems like an unattainable goal. In this series of posts, we’ll attempt to highlight some of the common problems encountered when trying to incorporate automated testing into development.

We DON’T do testing!

Some development teams lack any formal approach to automated testing. It’s still common amongst many teams, but over time, more and more teams are becoming test infected. Testing should really be a core part of development. Gerard Meszaros captures this very nicely when he said, “Not scrubbing before you go into surgery is a no-no, and not writing unit tests is not acceptable” (from Daryl Taft’s article Agile Brings Professionalism to Software Development).

Getting a development team to buy into any new approach is a major factor in it’s success or failure. Everyone needs to understand what they are doing and why they should be doing it. Only when the team has a clear understanding of the goals and benefits of testing, can it expect to make any real progress.

One of the simplest ways to achieve this, is to simply sit down a couple of developers and get them to write some code. The essence of this is not to show the developers what they should be doing, but let them try out the process for themselves. Both developers are asked to tackle the same problem using their preferred technique to deliver the finished code. Once the first problem is complete, the developers must write down all of the manual tests that have to be executed to prove the code works and demonstrate each of these. Once this process is complete, add another problem into the mix that has a higher degree of complexity. Again, the code must be manually tested and as the original code has also been updated, those regression tests must also be exercised. Rinse and repeat adding problems until you’re satisfied the problem has become complex enough.

The initial rounds of coding are accessible to most developers and the process is typically quite quick. As the problems become more complex and the changes to the existing code increase, the time taken starts to rapidly increase. Some developers write code that works first time everytime, but for the 99.9% of the others who make mistakes when they code, this time will also include deployment, manual testing, fixing the broken code and then repeating the process.

After the process has been completed, work through exactly the same problems again (from scratch) but instead of writing out the manual test cases, get the developers to instead write an automated test. There are typically some initial questions here but most developers can easily write a simple test case, at this point we don’t want perfect tests we just want SOME tests. After solving each problem and adding the additional unit tests, run the suite to make sure the code is still working.

It doesn’t take very long for the developers to get up and running with this approach, and when this is coupled with pair programming, it can be even more successful. Once this learning process has started, developers begin to see the benefits very quickly. Some developers take longer than others to convince, but overtime, many people find writing tests is actually quite addictive. I’ve have seen teams that either sit down in pairs or switch two developers and let them review the tests and spot any missing test cases. This can actually make testing quite competitive, in the same way that people dislike criticism (even though it’s constructive), people really don’t like being told they’ve missed a test case (or five).

It obviously isn’t always smooth, but it reinforces several facts about automated testing. The longer you have to maintain code, the more complex the code becomes, the more manual test cases there are and the longer a build-deploy cycle takes, the more compelling testing becomes. On many occasions I’ve seen people finally give in and start to write unit tests not when shouted at and told to by the lead developer, but instead, when they are sick of waiting for their application to load for the 100th time and just want to get their work finished. So the hard work is done, and most of the developers might have been convinced that writing tests is a good thing! It almost seems too easy. The CVS commit logs are riddled with classes ending in the test and the job is done, it’s probably time to do a quick review.

@Test
public void writeSomeTests() {
    assertTrue(true);
}

Ok, that’s not a good start!

Hiring Staff: Level 70s Need Not Apply?

After working in the technology industry for many years, I’ve had the pleasure of working with many avid gamers. Some of these are occasion players, but I’ve also worked with those that spent endless evenings and early mornings playing MMOs. The water cooler gaming banter is a regular occurrence; with discussions of last nights raid and the weekend guild meeting. It was therefore quite interesting when I started to read January’s edition of the gaming magazine edge which talked about hiring these same gamers.

“He replied that employers instruct him not to send them World of Warcraft players. He said there’s a belief that WOW player can’t give 100 per cent as their focus is elsewhere, their sleeping patterns aren’t great, etc. I mentioned that some people have written about MMOG leadership as a career positive, and he shook his head.”

After a little searching I found the original source of this quote and the proper context in which it was delivered. Although the opinion was that of a single recruiter and was merely a brief comment in a conversation, it seems to have generated a surprising amount of publicity (nearly 90k hits on the forum alone). Much of this was no doubt due to the telephone game nature of how this story was reported; in some reports it was a job interview, in others a huge employeer. The story had a life of it’s own and was reported in various incarnations, some widely inaccurate from the original. It did however touch a nerve and I was forwarded the same link several times from both gamers and none gamers.

It wasn’t so many months ago that I was reading about “the striking similarities between the skills required for online gaming and those required for real world leadership”. Jim Spohrer, Director of Services Research IBM said, “What we’ve found is that success as a business leader may depend on skills as a gamer”. Some people even went as far as to say that these games should be thought of as “a potential educational medium for complex social skills”. Others even contemplated resumes that include a line reading “level 60 tauren shaman in World of Warcraft.”

I have come across many hardcore MMO gamers who poses in-game qualities that any employer would jump at, but do these really translate into real world qualities? Are guild masters really project managers or lead developers in another guise? I’ve seen guild masters that organize every part of their weekend raid but I really wouldn’t be confident of letting them run the project schedule. Virtual world skills may help improve real world skills but I personally haven’t seen a correlation between the two. Guild masters may make great project managers but I wouldn’t personally use this status as an indication of potential ability.

Since reading the quote in the edge magazine, I’ve read more negative opinions about the impact these games have on individuals. Some anecdotal observations claim that playing these games is causing college drop-outs and led to people neglecting their studies. The results from a small poll even showed that 55% of people thought that MMO gaming affected their own school or work performance. The sample is small, but it’s still quite interesting that the very people playing the game claim it affects their own performance. Many follow up comments from the original story come to a similar conclusion; playing games makes you a less effective employee. But is that really true?

Balance and separation seem to be the dominating factors. Those gamers that I’ve really enjoyed working with were able to leave their gaming lifestyle at home, it’s something they do in an evening but it doesn’t take over their life. Those that really cause headaches think nothing of discussing group tactics and tech tree analysis during work, with the lunchtime forum reading quite easily turning into an afternoons reading. Morning naps are a common occurrence to make up for lost sleep when they were too busy the night before slaying the latest boss. But is this really any different to any other evening activity?

Everyone spends their spare time in different ways, but if that spare time activity starts affecting work on a regular basis, an employeer is completely justified to be unhappy about this. It doesn’t have to be a late night playing games, it could quite easily be a late night at the local pub or 4am coding on your own pet project. It doesn’t matter if last night you were a Death Knight, a Shaman a Warlock or just out partying, if you come to work an absolute wreck and the rest of the team have to make up for it, that’s just not on. When hiring staff, level 70s need not apply?

Spring Recipes: A Problem-Solution Approach

I recently had the pleasure of reading Spring Recipes: A Problem-Solution Approach. I first began reading the sample chapters released on the authors website, so when the book was finally finished I was really looking forward to getting hold of a copy. When it arrived I was amazed to see that it weighed in at a hefty 752 pages, but that really shouldn’t put you off.

Spring Recipes covers Spring 2.5 (and earlier versions) taking it from the simplest concepts right through to the most advanced level. The book is divided into nineteen chapters organised into three parts; Core, Fundamentals and Advanced. Each part builds on the previous ones to grow your understanding of all aspects of the Spring framework, for this reason the book is best read cover to cover.

This book is in no way filler and is packed full of content covering not only the Spring framework and but also several common Spring projects including; Spring Security, Spring Web Flow and Spring Web Services. For anyone that knows Spring (and it’s associated projects), this is a huge amount of information to cover in just one book, but this book really does deliver!

As the author puts it; “Reading Spring Recipes will help you master the most important 80 percent of Spring’s features with just 20 percent of the effort you would need to learn them all.” If you are already using Spring, this book will serve as an invaluable reference and companion guide for future development. If you are a newcomer to Spring, this book will serve as an excellent launch pad to get you up, running and productive with Spring very quickly.

Structure

Each of the recipes covered in the book follows; a problem, solution and then how it works approach. This approach lays out many of the common FAQ style questions that come up on Spring Forum in an accessible way; clearly outlining the problem and mapping the path to the solution. This book also acts an excellent companion to the Spring Reference manual, which is sometimes difficult to read in places and lacks the array of examples this book provides.

Audience

The intended audience for Spring Recipes, is any Java programmer hoping to learn more about Spring. No prior knowledge of Spring is required as this book covers it all right from core concepts such as inversion of control (or Ioc). This book is accessible to anyone who has heard the hype about Spring and simply wants to learn more about it and how they can leverage it’s power. This book gives Java developers hands-on experience using the Spring framework with real-world examples, this experience can be transferred straight into your Spring project.

Chapters

Part 1: Core

This part focuses on the core concepts and mechanisms of the Spring framework. The chapters in this part aim to familiarize you with Spring’s core. As a newcomer to Spring Chapter 1 introduces the concept of inversion of control the core foundation of Spring. It explains how and IoC container works, but also why it is useful and beneficial to use one. This chapter serves as an excellent introduction to IoC and is invaluable to anyone who isn’t quite sure why they should use a container based approach. This chapter is a must for anyone new to Spring or anyone trying to deliver it to a new audience.

Chapters 2-4 build on the IoC introduction, explaining how to setup and configure a new Spring project and apply the basics of Spring configuration. These first four chapters are the foundation for the rest of the book and are a must read for anyone who has never used Spring before and even advanced users may find useful hints and tips within. Chapters 5-6 cover the extremely powerful approach of AOP, introducing crosscutting concerns and how these can be configured with Spring. This technique can be extremely useful to provide trace logging, caching and other crosscutting concerns such as security. This is a must read for anyone using Spring, even if you are not directly leveraging Spring AOP or AspectJ. Spring AOP lays the foundation for introducing how Spring provides features such as transparent transaction support and method level authorization checking.

Part 2 : Fundamentals

This part has a split focus, it introduces Spring’s Data Access support, Web integration and also Testing support. Chapter 7 introduces one of the most important aspects of Spring’s data access support in the form of JdbcTemplate. This shows the reader how they can use JdbcTemplate to prevent the use of direct JDBC and instead let Spring handle all of the boiler plate code. As JdbcTemplate removes the need for the common try/catch/finally/try/catch code seen with JDBC, the code is much cleaner and much more readable. Along with this support, the Spring DataAccessException hierarchy is introduced which provides a rich set of common exceptions to provide a more granular handling approach.

Chapter 8 introduces Spring’s excellent transaction management support and explains in great detail all of the various propagation behaviours and isolation levels. This chapter is one of my favourites as it not only introduces the concept of Spring transaction support but transactions in general. It’s accessible to everyone and extremely useful when mentoring new developers.

Chapter 9 discusses how to integrate Spring with existing ORM frameworks, making their usage within the application seamless. This provides multiple approaches to integration allowing you to build on existing Spring classes, or completely decouple your classes from Spring removing the need for any Spring imports within your code. Chapters 10-11 discuss Spring’s popular MVC framework and also discuss how many other leading web frameworks can be integrated with a Spring application. As many of the projects I have worked on in the past have used Struts, Chapter 11 was particularly useful to outline all of the options available to use Spring and Struts together.

This part finishes with the introduction of Spring Testing Support, teaching you not only what features Spring has to offer but also how it integrates with popular testing frameworks such as JUnit and TestNG. As the Spring Testing support has been overhauled, it was great that this book covered the TestContextframework, but also legacy test classes to cover older versions of JUnit and TestNG. This chapter helps you leverage not only IoC for your tests but also transaction support, mock testing and also MVC integration testing. This approach enables you to easily decouple your code from your tests, providing first class support for all your testing needs.

Part 3 : Advanced

For anyone that has mastered the first twelve chapters, Chapter 13 is where things start to get really interesting. This chapter is dedicated to one of the most scary Spring projects, namely Spring Security (formerly known as Acegi). Spring Security provides a full range of authentication, authorization and access control options which allow it to secure a standalone Java application or a web-based application. This book focuses on version 2.x onwards which dramatically reduced the size of the required configuration and also its complexity. Spring Security can be a difficult subject to tackle as it’s often hard for developers to understand it’s concepts, but this chapter builds security into the example application in piecemeal steps. This demystifies many of the problematic areas of Spring Security whilst addressing the common problems a new developer might face.

Chapter 14 covers the portlet application development using the Spring Portlet MVC framework, highlighting the portlet-specific features which differ from the standard Spring MVC framework. If you don’t require the portlet features currently within your application, this chapter can safely be skipped as the next one is another gem. Chapter 15 covers the Spring Web Flow framework which addresses the three major pain–points facing web application developers: user interface navigation control, state management, and modularity. Spring Web Flow offers a flow definition language which encapsulates a reusable sequence of steps that can execute in different contexts. This framework is extremely flexible and powerful, but this chapter provides a great introduction into what is a very large subject.

Chapter 16 introduces the remoting integration that Spring provides for various technologies such as RMI, Hessian, Burlap, HTTP Invoker, and Web Services. Having already been familiar with many of these technologies, this chapter provides an excellent insight into how these can be integrated with Spring and how quickly this can be achieved. This chapter concludes with a look at Spring Web Services including how to develop contract-first web services. Chapter 17 discusses how to develop EJB 2.x and 3.0 components with Spring’s EJB support, and how to use Spring’s JMS support to simplify sending, receiving, and listening to JMS messages. This introduces a powerful concept of message-driven POJOsfor those who like the concept of message-driven beans (MDBs) but don’t want the restrictions of an EJB container.

Chapter 18 demonstrates how easily Spring beans can be exported as JMX MBeans with relative ease in comparison to the typical approach. It continues to extend this by providing remote access, auto-detection and notification. This chapter continues by introducing Spring’s email support which removes the reliance on JavaMail specific mail sessions and exceptions. This provides an abstraction which is independent making it easy to switch to another e-mail API. This chapter finishes with a look at the options available for scheduling tasks within the Spring framework, this integrates with the JDK Timer and also Quartz scheduler.

Chapter 19, this part and the book concludes with a look at the various scripting languages that can used with Spring applications including; JRuby, Groovy and BeanShell. One of the most powerful features of using scripts is that any changes made to these can be detected by Spring and thus the beans can be refreshed automatically. This is of great benefit when you wish to avoid the long compile, deploy and test cycles or the application cannot be taken down regularly for maintenance. This chapter demonstrates how scripted beans can be added to your application quickly and simply using Spring.

Summary

This book has undertaken a mammoth task, trying to squeeze Spring and associated projects all into one book. This book is very clearly written, with well-structured, concise examples that get to the heart of the problem without complicating it with unnecessary detail. The examples provide solutions to real world problems instead of taking the form of the simplistic examples found in many other technology books. My only real minor criticism of this book is it’s scope and size. Given the huge undertaking, there are obviously going to be some areas which only provide a minimal amount of information. This should be expected given the vast array of information covered, but there are a range of Apress books which can build on this foundation. I would still give this book five out of five and rate it as one of the best framework specific books I’ve read.

This book should accompany anyone starting their journey with the Spring framework and even seasoned developers. It can take you from knowing nothing about the Spring framework to knowing pretty much everything you need to create a fully functional web application with all the bells and whistles you’d expect. It provides information and examples on numerous integration points with other popular open source frameworks and languages allowing you to truly become a Spring expert. Read it, read it again and keep it on your bookshelf as a solid reference for the Spring framework.

Documentation: Update It Or Lose It

Over time I’m frequently restructuring and refactoring the code I work on to improve the design and simplify many of the balls of mud I find along the way. If I break some of that code my unit tests shout at me and if they don’t my continuous integration environment shouts at me when I’ve broken one of the integration tests. One area of the code that doesn’t receive the same attention however is the documentation.

I love a well documented API as much as the next developer. I also am fighting a constant battle to improve my JavaDoc skills, trying to write to the same quality that I see in many other projects. But is excellent documentation really enough? It can’t just be excellent when it’s written it needs to be constantly maintained to this same level over time.

It’s a pretty common occurrence that I can look at a section of code and find documentation that has nothing to do with the method it belongs to. The intention revealing name sounds nothing like the documentation which describes what it’s supposed to be doing. Somewhere in the mists of time, the intention of the method and the documentation parted company; it is documentation no more it is ex-documentation. The problem here however is that there’s nothing to catch this issue. If an extra argument is added, Eclipse might display a warning telling me it’s missing from the documentation, but the actual context of the documentation can be completely wrong and I am none the wiser.

Although this incorrect documentation may seem fairly harmless to some, the reason it was supposed to be there in the first place is to the give the user of the API information on the method contract and the expected outcomes. If this information is completely wrong however it introduces confusion and also potential misuse of the API. After much wasted time and several grey hairs later I recently filed a couple of JIRA reports about popular open source frameworks which did exactly this. After my code just didn’t work and the unit tests failed, it took me a number of minutes to realise that the JavaDoc description of expected events just didn’t reflect what was actually going on in the code.

One approach to solving this problem is to include the documentation in the frequent code reviews. Code that doesn’t have documentation or has incorrect documentation can’t be considered complete, thus doesn’t pass the review. Developers need to make sure however, that they treat the documentation with the same respect that they give to their code and their tests. When dealing with documentation I’d much sooner see a method with no documentation than something that is completely wrong. I do want a good level of documentation in the code I work on but there is a very simple rule; update it or lose it.

Embedded Database Performance: Handle With Care

Embedded databases are proving pretty popular with many teams finding their usage extremely appealing. Many embedded databases have impressive features; easy to integrate into the software, low administration requirements, very low footprint and generally extremely fast. It is for this last reason that some people look to these databases, but it is also for this reason that they need to be handled with care.

Just like OpenOffice, a previous project I worked on used an embedded version of HSQLDB. We had started to have several performance problems so engaged in some profiling to find potential areas for improvement. After staring at several screens full of SQL debug, one thing became apparent; our system was producing a huge number of SQL statements. This was accompanied by the realisation that it was also producing a huge number of exactly the same SQL statements.

As the embedded database was extremely fast, there had never been any performance problems before. In fact the database was not the bottleneck in many of the application operations. As the application grew more complex however, performance problems began to arise quite quickly. These problems only got worse when the numbers started to increase. Complexity + Scaling != Success. The extemely fast embedded database was now starting to be a real problem, some serious changes needed to be made.

Many of the database performance problems were resolved quite quickly by simply re-learning the most basic best practices, just because the embedded database was quick these should not have been ignored;

• Connection pooling can improve performance
• Statement caching can improve performance
• Batching statements can improve performance
• Performing SQL n + 1 selects are a bad idea regardless of how quick the database is
• Caching common SQL results can improve performance
• The database needs to be profiled to see exactly what SQL is getting executed against it

It may be possible to ignore these issues early in the project, but as the complexity increases and the application is expected to scale they can begin to be exposed. Embedded databases performance can be impressive, but make sure you handle with care.