Devoxx 2012 - Day 2

By Roland Huß |
Tags:

The second day of Devoxx is history, here are our impressions.

To ATDD And Beyond by John Ferguson Smart (roland)

John introduces Aceptance Test Driven Development by giving an oveverview of the various levels of agile requirements engineering: Features must be connected to higher level goals. These features lead to a set of user stories, respectively. Each user story in turn has a set of acceptance criteria. These criteria should be checked and verified with automated acceptance tests. That’s it.

Automated acceptance are perfect suitable for providing documentation of you acceptance criteria and hence provide better visibility. Even when writing automated acceptance tests, it turns out, that you can deliver faster at the end with lesser bugs. Finally, automated acceptance tests reduce risks.

Good point: “Real quality cannot be inhected at the end, it must be part of the process”, so QA only at the end of the delivery chain is not sufficient.

The first tool introduced is “Thucydides”, which helps you to discover acceptance criteria, automate and implement them and executing the tets.

Thucydides helps you to organize your acceptance tests implemented e.g. by JBehave into scenarios. It also integrates with various management systems like JIRA.

Next, Thucydides helps in structuring your tests. Selenium’s Webdriver has the concept of page objects to encapsulate the inner structure of a certain web page, but it is still too low level for acceptance tests. Thucydides dies this via so called Steps which further hides the interaction with page objects.

Thucydides addes a fluent API and helper methods for dealing with WebObject pages. It also had static method for building up fluent matchers (on top of Hamcrest matchers) and fluent waits for waiting on results appearing on the page.

Some WebDriver tips:

  • Prefer CSS to XPath, because it is a lot faster and easier to read and maintain.
  • Confine Webdriver to Page Objects
  • Webdriver query is similar to a JDBC Query in terms of excution speed.

Part 2 of the talk is a live coding session. For an example Web-Shop a set of tests are implemented with JBehave and Thucydides.

All in all this was very comprehensive introduction into ATDD. And also John was a bit ill, he managed to transport the essential ideas of ATTD along with concrete tooling tipps. As always, John’s presentation was technically very well crafted, too.

A Crash Course on frontend performance by Ilya Grigorik (roland)

This tour-de-force lasted 172 minutes without a single break. There was so much interesting, performance related stuff packed into this presentation, which makes it really hard to summarize.

The motivation for optimizing web performance can be derived from the following numbers:

  • 0 - 100ms : Instant
  • 100 - 300ms : Feels sluggish
  • 300 - 1000ms : Machine is working
  • 1s+ - Mental context switch
  • 10s+ - I’ll come back later

The to shoot for is 250ms, which luckily is a concrete number to check against.

All layers (TCP, HTTP/SPDY, HTML) were covered with very concreted numbers and tipps. Instead to sum up this talk (which is really impossible within a single blog entry), let me pick the list of hands-on recommendations for what to look out when it comes to Web performance:

  • Reduce DNS lookups
  • Avoid redirects
  • Make fewer HTTP requests
  • Flushing the document early
  • Use a CDN
  • GZIP text assets
  • Optimize images, pick optimal format
  • Add an Expires Header
  • Add ETags
  • Place stylesheets at the top
  • Load scripts asynchronously, wenever possible
  • Place scripts at the bottom
  • Minify, concatenate
  • Build buttery smooth pages (60 FPS ~= 16.6 ms per frame)
  • Leverage hardware acceleration where possible
  • Eliminate JS and DOM memory leaks
  • Test on mobile devices

I really recommend to watch this presentation on Parlyes when it comes out or at least have a look at the slides (which should also be public available soon). This was so far the presentation with the most concrete, hands on tips and numbers here at Devoxx.

JUnit Rules by Jens Schauder (roland)

Frequent problems with Tests are missing clean ups (tear down), so that tests fails randomly. Another issue is when to inherit from multiple base classes. Multiple runners and repetitive code are other issues.

Rules take a JUnit Statement and transform it into another statement. Rules are declared with the @Rules annotation. So, rules are somewhat like global interceptors for tests providing some crosscutting concern functionality. That’s all, I guess.

Examples for rule usages:

  • Timeouts
  • Setting up the runtime environment like running them within the Event Dispatch Thread for Swing tests.
  • Conditionally ignore Tests.

Rules can be chained, with a RuleChain. Also, class rules can be defined with @ClassRule which wraps around the whole test.

Also rules can be simulated with TestNG as welll (see this StackOverflow Answer), I think rules are better in encapsulating cross cutting concerns into separate code classes.

The talks itself was good and 25 minutes were exactly enough in order to explain this lesser known, undocumented but quite nice JUnit feature.

How to solve memory leaks within minutes with Plumbr by Nikita Salnikov-Tarnovski and Priit Potter (Georgi)

Plumbr is a memory leak detection tool which is implemented as Java Agent. It is just an interceptor in front of your application, executed in the same JVM as your application and loaded by the same classloader. Using a specific algorithm Plumbr tries to detect possible memory leaks.

Here are some interesting facts about Plumbr

  • 10% memory and 23% cpu overhead - quite much at the first sight, but you are not running it every day ;)
  • supports for all JVMs and versions 5,6 and 7
  • 90%+ of memory leaks detection, which is quite impressive
  • the result is a report containing the detected memory leaks

It is quite easy to use, just register it as javaagent and enjoy it :) As part of the demo Plumbr was also able to detect a classloader leak caused by multiple redeploying of the application.

One point which has to be mentioned, is that Plumbr is not completely free. It is free if it doesn’t find any leaks within your app. As soon as there are leaks found by Plumbr, you are getting a report with some information, but you have to buy the app to be able to get the whole report, which contains all informations about the leaks.

I have to say, that I have enjoyed the talk. Nikita and Priit have tried to do it a bit amusing and I think, that they have done this quite good.

Don’t hesitate to give Plumbr a try.