Tag Archives: Tips

Agile Australia 2012: Agile Coaching Workshop

Posted on by

See on Scoop.it – catosplace

My workshop from Agile Australia 2012 with Adrian Smith called “Agile Coaching Workshop” is available on SlideShare. The Agile Coach is a critical role in helping leaders, teams or individuals…

I was unable to attend Agile Australia 2012 and as a result missed out on what looks like an awesome “Agile Coaching Workshop” presented by former colleagues Craig Smith and Adrian Smith. These guys have many years of practical experience between them, and as mentioned once before, when they speak it pays to listen.

The slides from the workshop are available on Slideshare and on Craig’s blog (which is where this post links to). Although these are only slides they contain a lot of content that will be useful for those unable to attend the workshop. A preview of the slides had previously been posted and shared by myself too.

For me the section on identifying personal areas of strength and weakness provided me with ideas for improvement – and where I could broaden my skills  in the coaching department. I shall be trying out the Agile Coach Competency Matrix and contacting one of the guys for some advice.

I am not an Agile Coach by title and never considered myself a coach – I feel I am more of a Agile practitioner trying to support teams and leave a legacy that will being maturity and delivery success long after I leave. These slides whilst not making up for missing the workshop may give you ideas for assessing and improving your own Agile skillset.

Am sure the guys would appreciate some feedback on the slides and would love to hear from anyone who attended the workshop. I wonder if either Craig or Adrian would fancy presenting a version of the slides at the Agile APN in Auckland some time?
See on craigsmith.id.au

Improve Developer Quality Tip #1

Posted on by
Writing Computer Code

Writing Computer Code

This is the first in an ongoing series of tips for improving developer quality. Each tip will highlight development skills that I believe help improve code quality. Skills developers can learn via the resources linked to in the tip. Skills that once mastered will lead to better quality solutions.

#1 Transaction Models & Strategies

This first tip looks at transactions. Good developers can tell you that transactions need to have ACID (atomic, consistent, isolated and durable) properties. They will also be able to tell you that transactions help recover from failures and help to keep the data in a consistent state.

Continue reading “Improve Developer Quality Tip #1” »

JUnit 4 Test Logging Tips using SLF4J

Posted on by

SLF4J LogoWhen writing JUnit tests developers often add log statements that can help provide information on test failures. During the initial attempt to find a failure a simple System.out.println() statement is usually the first resort of most developers.

Replacing these System.out.println() statements with log statements is the first improvement on this technique. Using SLF4J (Simple Logging Facade for Java) provides some neat improvements using parameterized messages. Combining SLF4J with JUnit 4 rule implementations can provide more efficient test class logging techniques.

Continue reading “JUnit 4 Test Logging Tips using SLF4J” »

JUnit Goodness

Posted on by
Testing: The Dark Side?

Testing: The Dark Side?

It feels like an eternity since I last sat down to write some blog content!!

The last month or so I have been busy updating a ‘JUnit Goodness’ presentation for use at the Auckland JUG October 2009 meeting. The presentation focuses on 3 aspects of JUnit 4 that I feel may have slipped under the radar of developers introduced to JUnit at version 3. Parameterized tests, matcher assertions and the @Ignore annotation were the 3 aspects I chose to include in this presententation.

The parameterzied test section of the presentation attempts to outline a process that may lead a developer to utilize a parameterized test. The realization that duplicated code can be replaced by a looping test leads the devloper naturally in  the direction of a parameterized test. The presentation aims to offer answers regarding why and when to use parameterized tests and how to write them. Also included in the presentation is a named parameterized test extension and an XML data driven parametrized test extension that I had recently implemented.

Matcher assertions arrived in JUnit 4 via JMock. The presentation aims to demonstrate the advantages of using matcher assertions compared to the legacy JUnit assertions. Matcher assertion readability, clarity of failure messages, combination matcher usage and the benefits of list matchers are all presented. The creation of custom matchers is also present, albeit through a crude over simplified example.  To finish the presentation there is a look at the somewhat under utilized IMHO @Ignore annotation and how it can fit in to improved testing practices.

Auckland JUG Duke

Auckand JUG Duke

The majority of those present at the presentation were still using JUnit even though TestNG has built up quite a following and viewed by some as the next generation test tool. TestNG has useful features such as parallel testing and data driven testing using the @DataProvider annotation that JUnit does not. Why has there not been a shift to this next generation test tool? Is it down to the lazy developer syndrome? The we know this tool, why waste time learning a similar tool attitude? Some of the attendees were aware of TestNG and the benefits it offers when writing certain types of tests – yet still used JUnit for there project test needs.

Many of those present were unaware of the benefits that the 3 aspects presented provided. There was the odd attendee who had dabbled with one or two of the aspects, but none had really dug too deep. Hopefully I provided everyone with something to think about whenever they are writing JUnit tests in the future.

I had expected the parameterized tests section, particularly the named and XML data-driven extensions would be the ‘WOW’ factor of this particular presentation. This was not the case though. The actual ‘WOW’ factor turned out to be the clarity of the matcher assertion failure messages compared to their legacy equivalents. Flicking between the two versions on the big projector screen seemed to exacerbate the clarity.

I would be surprised to see any of the developers present not using matcher assertions from now on based on what they saw. The @Ignore annotation usage did lead into a group discussion regarding how useful it was, how it could be abused and the best ways to use it.

I plan to upload a slightly updated version of the presentation to SlideShare later this week.

Purchase JUnit In Action 2nd Edition MEAP Edition

Purchase JUnit In Action 2nd Edition MEAP Edition

Eclipse Tip #1 – Static Import Code Completion

Posted on by

If like me Eclipse is your IDE of choice and you find yourself frustrated by having to add an import statement in order to use common static imports then help is at hand. If you use JUnit 4′s assertThat method, the core Hamcrest matchers or even EasyMock verifiers etc, then this tip will make your life easier.

In order to simplify using these static methods add them to your Eclipse static import favourites. This little gem of functionality is found under Preferences -> Java -> Editor -> Content Assist -> Favorites.

Eclipse Static Import Favouries

Eclipse Static Import Favouries

In the above example I have added the org.junit.Assert.* package to my favourites. Now when I am working on some java code and want to use a static import from this package it will be available in the code completion box, as can be seen below.

Code Completion Static Imports in Eclipse

Code Completion Static Imports in Eclipse

Acknowledgment for this simple tip and a few more must go to Benjamin Winterberg who provided this in his 5 Tips for Customizing Eclipse blog entry. Vote his entry up on DZone by voting here.  Hopefully this tip will make your Eclipse static import use a pleasure and not a frustration from now on.