Presenting at Gradle Summit

In a little over a week and a half, I’ll be presenting this session at Gradle Summit in Santa Clara

Single Page JavaScript Webapps … A Gradle Story

Most people ask me why we chose to use Gradle over a JavaScript build tool.  It was a small circumstance that we took this path. Usually most companies begin their new JS project with Grunt or Gulp.  We tried the same path but it was an unfortunate case at the clients site, their firewall that prevented us from using npm to download npm modules.  We tried to get around this but since we already were using Gradle and it could get around the firewall, we put it through its paces.

In addition, the pace of JS build tool momentum is a little ridiculous. Every time I visit a JS meetup there is a new tool on the scene for managing builds. I’m not sure where to invest my time in learning a tool if the flavour of the month changes so regularly.

Many Java projects have picked up Gradle. There is low configuration required to get a build up, but you are allowed to declare more as required to customise the build for your world.  Since many JVM devs are learning Gradle, and have migrated some of their projects to the new build tool, the barrier for a Java dev to use this tool to build projects on other platforms like JavaScript isn’t too hard.

In this talk we’ll cover getting a simple build up for a simple single page JavaScript web app covering the functions that are available in Gradle for processing JavaScript & CSS resources. We’ll look at some cool features you can get by integrating Jetty so that developers can checkout and run the project in an interactive way. Other tricks and tips covered whilst developing our project will be covered.  Finally, grunt and gulp are the two main contenders in the JS build space. We’ll provide a quick overview of how they work and where you’d want to bring these into your build.

If you are in the area and can come to gradle summit, please come along to watch!

 

 

Junit Kungfu

A great presentation with audio that talks about Junit 4, test naming and other things.  I liked this presentation because it starts expression Behaviour Driven Development concepts without actually using a Behaviour Driven Development Framework.  Additionally its one of the more in-depth presentations covering the new features of JUnit like Rules.

The presenter is John Ferguson Smart who runs testing and agile tools bootcamps around Australia and NZ (as well as elsewhere) so if you are in the vacinity you should consider looking into em.

My notes from the presentation:

Naming tests

Dont use the name testXXX – you aren’t testing methods of your code

You are testing use cases – what should your class be doing

Take out private methods, maybe extract to a separate class and test those separately if they are getting too big.

Use the word should.  Express an outcome

Class Name: When is a behaviour applicable
Method Name: When at is the behaviour testing

Tests become more readable.

Arrange-Act-Assert

Create the test collaborators – Inputs and Expected Outputs (Arrange)

Test the behaviour (Act)

Verify behaviour is correct (Assert)

Extending Hamcrest Matchers

Combine matchers together – hasItem(someOtherHasPropertyMatcherYouPreviouslyDefined)

Create a new matcher –

  1. Extend TypeSafeMatcher<type of thing you are checking against)
  2. Implement Constructor take in  a matcher of expected value
  3. Implement matchesSafely(type of thing you are checking against)
  4. Implement describeTo – decorate the existing test result/matcher description…  description.appendText(“WuzUp!”); matcher.describeTo(Description);
  5. Create a Factory Class for your matchers with static factory methods to return a new matcher
  6. Use It

Multiple asserts per test are bad (see also Integration Tests are a Scam)

You can combine hamcrest matchers into one test

assertThat(itesm, allOf(hasSize(1), hasItem(“java”)));

assertThat(itesm, hasSize(greaterThan(1)));

The error messages will be cleaner too – expect list size of one, and has item java but received <blah>

Parameterized Tests

Usually just one test per Parameterized test class – they get run once

Ways to get test data

Use an xls spreadsheet source

Use Selenium 2’s WebElement to get a webpage

@FindBy(name="HD_EN") WebElement importerName;
@FindBy(name="HD_EA") WebElement importerAddress;
@FindBy(name="HD_ER") WebElement importerRepresentative;

// getters and setters
 // getter return importerName.getValue();

// setter
public void setImporterName(String value) {
     enter(value, into(importerName));
}

Smoke test to make sure getters and setters are correct

image

Make sure the annotations aren’t wrong

JUnit Rules

Delete folders after test run

@Rule public TemporaryFolder folder = new TemporaryFolder()
folder.newFile(“a file name”);

ErrorCollection,

accumulate errors rather than fail on first.  This saves having to write 20 different tests with large setup that check 20 things on the same page (eg login and load webpage table then verify each cell)

@Rule public ErrorCollector collector = new ErrorCollector();
// in your test
 collector.addError(new Throwable(“blah”));
collector.addError(new Throwable(“something else”));
collector.checkThat(result, yourMatcher);

The result will show “blah”, “something else” and the result of your failed matcher, as well as fail the test.

TimeoutRules

When you know something should have a short response time, a DAO for example should be shorter than 1 second

@Rule public MethodRule globalTimeout = new Timeout(1000);
@Test public void catchInfiniteLoopInTest() { for(;;); }

Catch any major issues before they get into production and become embarassing

Verifier Rule

Something that happens after a test is completed, like an assert

Inject behaviour to make JUnit add checks after each test…. kind of like a test post-condition or invariant from Betrand Meyers OO Software construction, but just for the tests themselves.

private List<String> systemErrorMessages = new ArrayList<String>();
@Rule
public MethodRule verifier = new Verifier() {
    @Override
    public void verify() {
        assertThat(systemErrorMessages.size(), is(0));
    }};

A good example I see would be using it to tie up mock verification calls in EasyMock

Watchman Rule

Called when a test fails or succeeds.  Additional logging perhaps?  How about restarting a GUI, or take a screenshot when a test fails.

Categories

Group tests in your own hierarchy based on your classification of the test rather than writing test suites.  Performance tests  that integration tests.  Slow running or fast running tests?

You can setup plain old normal interfaces for your categories, and have them extend each other via subclassing.  There is no Junit annotation here to indicate its an interface for testing, so you can potentially use any interface in your source.  I’m not sure if this is good practice or not, but say you wanted all your DAO tests that implemented a GenericDAO to be tested, you could do this…. or how about test all classes that implements Serializable?

You can annotate a test class, or tests methods with @Category(InterfaceName.class)

When running a category suite however you still need to include the classes to inspect as well as the category name.

@RunWith(Categories.class)
@IncludeCategory(PerformanceTests.class)
@SuiteClasses( { CellTest.class, WhenYouCreateANewUniverse.class })
public class PerformanceTestSuite {}
You can also exclude from a Run and run a
@RunWith(Categories.class)
@ExcludeCategory(PerformanceTests.class)
@SuiteClasses( { CellTest.class, WhenYouCreateANewUniverse.class })
public class PerformanceTestSuite {}

But how about scanning your whole test bed?  Can we programmatically inject suite classes and use them with Categories?  At this point it is a limitation unless you want to use a classpath hack.

Parallel Tests

If you have fast IO and multicore (like my new work PC Smile) and well written tests that don’t trodd on each others data.

U use Maven’s surefire 2.5 plugin to achieve this, and say methods, classes or both in parallel.  Classes is probably safer since most people write the test slipping thru later tests in the same class depend on earlier test methods accidentally.

Infinitest

This is a tool for IntelliJ and Eclipse that runs tests when you save your source and tells you if you have failed runs.  I remember twittering about how cool this would be if it existed a while back, and I’m glad I wasnt the only one with this idea and that someone actually implemented it Open-mouthed smile.

Also there was a plugin for IntelliJ called Fireworks but I could never get it to run tests properly on my Windows PC; always complaining about not being able to find a JDK home Sad smile.

This tool seems pretty cheap at $29 for an individual license, I’ll check it out and give it a shot.

http://improvingworks.com/products/infinitest/

What would be super cool is if it worked with Categories mentioned above, to be able to exclude GUI tests from being executed.  There may be a feature in Infinitest that handles it but I’d be keen to see.

Mockito

I’m traditionally an EasyMock guy but Mockito has always had good buzz.  At my new job we dont actually have a mocking framework yet so I’m keen to give it a look.

Mockito seems to have less verbose setup of tests, something that when learning EasyMock bashed me around a bit – ever forget to get out of record mode and get a green test accidentally.

As per Integration Tests are a scam ypresso recommends, you can verify interactions, verify a method is being called with certain params.

Other Stuff (comments from the Q&A of the presso)

Hibernate mappings – use an in-memory database

FEST asserts – an alternate to Hamcrest that avoids the Generic issues that plague Hamcrest!!! (boy this frustrates me a lot as a Hamcrest user)

Cobertura – a code coverage tool, alternate to Emma

Private methods shouldn’t be tested explicitly – you should be able to sufficiently test a class by its public facing API.

Seven Groovy usage patterns for Java developers

A colleague at my work recently added a Groovy console into one of our applications and it was this that reminded me of the ‘keyhole surgery’ pattern that I watched in a presentation last year by Groovy In Action author Dierk Konig last year…

Seven Groovy usage patterns for Java developers

Dierk König, Canoo Engineering, Switzerland

Groovy is the new dynamic language for the Java platform that any Java?project can benefit from.?Learn when and how you can use Groovy as a “Super Glue”, heat up your Java?application with a “Melted Core”, alleviate pains with “Keyhole Surgery”,?adapt it to local needs with “Smart Configuration”, let it achieve?”Unlimited Openness”, enjoy subserving “House-Elf Scripts”, and provide?early feedback from a “Prototype”.

via Viddler.com – Øredev 2008 – Cool Languages – Seven Groovy usage patterns for Java developers – Uploaded by oredev.

CamelCaseString to Space Separated String

groovy> print 'CamelCaseString'.replaceAll(/([A-Z][a-z]*)/, '$1 ').trim()
Camel Case String

There is probably a better regex approach that does not a space to the final word, and thus remove the need for a trim, but this is quick and easily embeddable anywhere, for example, in a jasper report groovy expression. Winking smile

Hyperic HQU Monitoring

As a software dev who worked with an ISP, I learnt monitoring is a big thing.  Customers have availability metrics we need to meet, and more importantly customers are paying for a service.  When it goes down, they shouldnt have to be the ones to call it up to let you know, and they should also find out about an outage as early as possible.  Well before their bosses come knocking on their door.  And regardless of size, monitoring is still a big deal for any sized company and support team, and glad to say of interest at the company I work for now.

In the last 12 months I’ve been getting to know the Hyperic Monitoring Platform.  It has an open source community edition with an automatic free barrier to let small teams monitor what is important.  Additionally it is easily configurable via a web UI, which allows non-technical staff to add monitoring, setup alerts and that sort of thing.  Most importantly it is configurable via an api (or two).  There is the HQ API which is a REST api, and the Groovy API. 

I haven’t need to venture into the API at all to date but did recently get asked the question if HQ was able to export views and reports.  The good news after watching this vid is that you can.

The interview with Jon Travis reveals that the API is not only capable of exporting its information, but it also allows developers to add screens into their HQ installs. 

Graph Databases

A great article on the NoSQL movement, focusing on Graph Databases and the Neo4J implementation appeared on InfoQ.

Graph databases store a Node (aka vertex), that has properties (aka attributes), that is then linked to another node.  The relationship (aka edge) between the nodes also has properties and has a direction and a type.

The article demonstrates that syntactically these databases look easy to manipulate. In Ruby (and presumably Grails) they map directly to classes and with the use of metaclasses and operator overloading, to allow the domain objects to be quickly in a neatly expressive way.   For Groovy/Grails/Griffon, there is info on the Neo4j wiki

Because OO models are graphs, the need for ORM layer is removed.  They map directly to the classes we are trying to store.  Additionally the pain of upgrading the data in a class is reduced since adding a new column is less painful.  More benefits can be found on the Neo4J website.

Neo4J is free for open source projects and there is an unsupported free single instance Basic edition for startups, but is paid for everyone else.  There are 3 commercial editions, basic, advanced and enterprise priced at $588, $5,988 and $23,998 per annum (billed as monthly subscription).  The free Basic is a good move, small companies who may elect a free alternative such as MySQL, Postgres or even the Oracle Express Edition.  For the Basic & Advanced editions, you could argue that the development time saved would more than cover the fees charged. 

The basic edition lacks monitoring which in my opinion should be included, especially if you are only going to get 2 support incidents per year with that package.  However the advanced edition has that feature plus monitoring, a management console and allows hot backup and failover to a 2nd running node. It only differs itself from the high end one due to lack of high availability features and longer support response times.  If you were using it for a production enterprise system, you’d probably want the 24/7 support and I think this pricing is comparable to a support subscription for any of the larger RDBMS vendors and with no upfront capex fees to note, though keeping in mind that at the enterprise level you’d be paying for multiple running nodes costs may run up quickly —- there is always negotiation though in this space.

Design your own DSL with Groovy

http://www.infoq.com/presentations/Design-Your-Own-DSL-with-Groovy

This presentation is by Guillaume Laforge, one of the Groovy founders, who does quite an interesting presentation about how Groovy supports Domain Specific Languages.

In short he starts with a simple example of how the Groovyisms in the language such as method calls without the need for parenthesis, named params and maps and list param injection into method arguments make for readable DSLs, all without touching any of the fancy meta-programming functions provided.  Very impressive. Other Groovy features that we sometimes forget about are ranges and operator overloading which were demonstrated here and  improve readability.

Then he scratches the surface a little deeper showing an example of how to add methods to existing classes using the metaClass property.  He takes the Number class and dynamically adds a method that constructs an object representing a measure – 6.pills or 6.euros which call a method Dosage getPills() that you inject into Number. 

   1: Number.metaClass.getPills = {

   2:     return new Dosage( numOfPills: delegate );

   3: }

When combined with the previous readability of maps representing method args and parenthesis less method calls, it can lead to some readable code

   1:  take  1.pills

   2:   of: SomeDrug,

   3: after: 6.hours // Number.metaClass.getHours = { … }

take is defined as

   1: def take(Map m, Dosage d)

This is a great intro to metaClass object protocol for those who haven’t come across it in Groovy.

The last part of the presentation talks about Abstract Syntax Tree transformations and how you can inject syntax into the Groovy language using annotations.  He uses the example of the Spock testing framework and how the @Speck annotation injects behaviours that wouldn’t normally be allowed in Groovy or Java, such as method names which are “strings with spaces and question marks?” and other neat stuff.  He also talks about how its important to limit what your DSLs can do in the JVM if you are giving them off to

I think in summary Groovy is a great language for supporting DSLs and the presentation gives a valuable insight into some of the more advanced groovy features, a worthwhile watch.

Junit’s Theory’s as interprested by Schauderhaft and Groovy

JUnit theories sound promising.  Many a time a developer writes a whole lot of @Tests along the lines of testParameterXzero(), testParameterXone(), testParameterXmaxInt(). The test code may be almost identical apart from the parameters being used in the class/method under test which is redundant and prone to error.

Theories offer a sound alternate, specifying a single test method, with a different set of annotations to the regular @Test defining a field or annotation based ParameterSupplier to inject a series of values into each test.

Schauderhaft’s blog provides a great summary of what theories are and how to write a parameter supplier to supply a series of datapoints in Java. The annotation based ParameterSupplier does look a little verbose but as Schauderhaft points out, they can be reused – annotation based data fixtures – excellent. I liked these two posts because they do a better job at explaining than the release notes. The blog also links to a blog about another Junit4 feature – parameterised tests – that seem to be a precursor to Theories, and a little simpler to setup. Another great source of how to use Theories is actually in the Groovy documentation about Junit integration. Closures make Datapoints a little more concise (or maybe the example is just simpler? hehe) along with the fact that test data (lists,maps) have a groovy conciseness to them to begin with.