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.