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
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:
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.
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
The to shoot for is 250ms, which luckily is a concrete number to check
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:
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.
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
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:
Rules can be chained, with a
RuleChain. Also, class rules can be
@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
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
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
Don’t hesitate to give Plumbr a try.