Holy on Dev

Archive for September, 2011

Most interesting links of September

Posted by Jakub Holý on September 30, 2011

Recommended Readings

  • J. Yip: It’s Not Just Standing Up: Patterns for Daily Standup Meetings – it isn’t easy to make stand-up meetings short, focused, energizing, and centered around continuous improvements and team spirit. This description of an example good standup, the meeting’s goals, and especially the “patterns” and “bad smells” can be pretty useful to get and keep on the track towards a brighter future. TBD: standup goals: GIFTs, team spirit, appreciation where we go and are.
  • M. Poppendieck: Don’t Separate Design from Implementation – according to Mary, (detailed) requirements – being it in the form of (backlog) user stories or any other – represent actually a design of the system, which shouldn’t be done by the amateur product owner/business analyst but by professionals, meaning the developers, based on high-level goals and clear specification of the desired business value. She writes about a project that her factory outsourced and which she could have designed but didn’t – yet it succeeded even though there were no detailed requirements. I’ve also read and unfortunately lost an interesting answer where the author argues that that is only possible if the developers are really experienced in the field. I tend to agree more with Mary though it is of course a question what “high” and “low” level goals/requirements are. But undeniably users/analysts tend to propose solutions disguised as requirements while often missing the technical insight to see possible other and better solutions. We also cannot expect the developers to produce a great SW if the true goals, needs, and business values behind the requested “features” aren’t clearly communicated to them. (The best example – lost source again – is where a developer proposes to the client a simple process change that will solve the problem without writing a single line of code.)
  • Mike Cohn: The Forgotten Layer of the Test Automation Pyramid – three levels of testing with increasing number of tests: UI/Service/Unit (or end-to-end instead of UI), each requiring a different approach. Unit tests are best because a failure points directly to its source (with higher level tests you don’t immediately know the cause). The higher in the pyramid, the less tests we should have (e.g. because of their redundancy). It’s important not to forget the middle, service layer – unit tests are too low-level, UI tests too difficult and brittle. Also Gojko in Specification by Examples says that acceptance/BDD tests should run mainly at the service layer because of the UI level issues.
    “Although automated unit testing is wonderful, it can cover only so much of an application’s testing needs. Without service-level testing to fill the gap between unit and user interface testing, all other testing ends up being performed through the user interface, resulting in tests that are expensive to run, expensive to write, and brittle.” [Emphasis JH.]
  • Technical Debt and the Lean Startup – Paul Dyson remarks that while quality is an essential concern for projects in established environments, in the case of lean startups the primary goal is to find out whether a product is viable and what it should be like and thus it’s reasonable to accept much higher technical debt by not spending too much time on ensuring scalability, de-duplication etc. – only when the product proves viable should we start to care for its long-evity by emphasizing the quality. But one thing can never miss and that is good test suite because this is the crucial factor that makes letter payment of the technical debt possible without ruining oneself.
  • Coding dojo – Real time coding competition with Extreme Startup – an inspiring report about a coding dojo lead by Johannes Brodwall in Bergen’s JUG, the task being the implementation of a server that can respond to questions send over HTTP (that’s all participants know at the beginning – they learn the rest during the iterations)
  • Using Code Katas to Improve Programming Skills – why to use code katas + links to different proposed katas
  • Kent Beck: Don’t Cross the Beams: Avoiding Interference Between Horizontal and Vertical Refactorings – when to do depth-first (more exploratory) refactoring and when to extend it into breadth (i.e. apply it to several similar objects)

Learning Clojure (maybe not so interesting for those not learning the language)

  • Phil Calçado: My Experience With TDD In Clojure (via planetclojure) – nice example of how to decompose a task in functional programming to make it easy to test (via Midje), including useful testing-related links and a discussion of side-effect isolation and the building blocks of functional programs, i.e. function composition using combinators (i.e. functions producing functions)
  • How to learn Clojure effectively (via planetclojure) – a very good description of how the task at  4Clojure (though I prefer Clojure koans) should be solved to benefit one’s learning the most plus some general tips on functional thinking
  • Clojure open source projects for learning how to code it

Posted in General, Testing, Top links of month | Tagged: , , , , , , | 1 Comment »

Inspect Your Webapp in a Live Environment Interactively with GroovyConsole

Posted by Jakub Holý on September 27, 2011

Have you ever needed to check the state of your webapp’s objects/Session/.. to find out why the hell something doesn’t work or have you had to learn a weird 3rd party API that is only available on the server? Then you were doomed … until the publication of GroovyConsole. JeeUtils GroovyConsole provides a JSP page that let you execute any Groovy/Java code on the server side, with access to server-side objects like request/session etc.

Here is a screenshot of my recent troubleshooting session, where I needed to check the state of a session-scoped JSF Managed Bean:

Read the rest of this entry »

Posted in j2ee, Languages, Tools | Tagged: , , , , | Comments Off on Inspect Your Webapp in a Live Environment Interactively with GroovyConsole

JUnit Tip: Verifying that an Exception with a Particular Message was Thrown

Posted by Jakub Holý on September 16, 2011

JUnit has a hidden treasure which makes it easy to do something we have long longed for – namely not only to verify that an exception of a particular type has been thrown but also that its message contains the expected message. The hidden pearl is the @Rule ExpectedException and its JavaDoc documents well how to use it (slightly modified):

Read the rest of this entry »

Posted in Testing | Tagged: | 6 Comments »

Link: Advanced Usage of JUnit Theories, Multiple DataPoints, and ParameterSuppliers

Posted by Jakub Holý on September 16, 2011

It is surprising how difficult it is to find documentation for some JUnit features such as Theories. May be they haven’t bothered to write it because it is still considered “experimental” (even though included in JUnit since 4.4). As usually we have to rely on Jens Schauder’s blog and I’d like to draw your attention to his post describing advanced usage of JUnit Theories including things like

  • multi-argument @Theory methods (each argument’s value taken from a different set of data points thanks to their different data types),
  • @TestedOn as an in-place values supplier, and
  • use of org.junit.Assume.assumeThat,
  • the use of parameter suppliers (create a marker interface annotated with @ParametersSuppliedBy(YourImplementation.class), create the implementation extending ParameterSupplier, and annotate your theory’s argument with the interface)

Thank you, Jens!

Posted in Testing | Tagged: | Comments Off on Link: Advanced Usage of JUnit Theories, Multiple DataPoints, and ParameterSuppliers

Correct your URL

Posted by Jakub Holý on September 7, 2011

The page you want to access is Practical Introduction into Code Injection with AspectJ, Javassist, and Java Proxy

Sorry for the wrong bit.ly link 😦

Posted in Uncategorized | Comments Off on Correct your URL

Practical Introduction into Code Injection with AspectJ, Javassist, and Java Proxy

Posted by Jakub Holý on September 7, 2011

The ability to inject pieces of code into compiled classes and methods, either statically or at runtime, may be of immense help. This applies especially to troubleshooting problems in third-party libraries without source codes or in an environment where it isn’t possible to use a debugger or a profiler. Code injection is also useful for dealing with concerns that cut across the whole application, such as performance monitoring. Using code injection in this way became popular under the name Aspect-Oriented Programming (AOP). Code injection isn’t something used only rarely as you might think, quite the contrary; every programmer will come into a situation where this ability could prevent a lot of pain and frustration.

This post is aimed at giving you the knowledge that you may (or I should rather say “will”) need and at persuading you that learning basics of code injection is really worth the little of your time that it takes. I’ll present three different real-world cases where code injection came to my rescue, solving each one with a different tool, fitting best the constraints at hand.

Read the rest of this entry »

Posted in Languages, Tools | Tagged: , , , , | 9 Comments »

DRY: Use JUnit @Rule Instead of Repeating Setup/@Before in Each Test

Posted by Jakub Holý on September 4, 2011

I was for a long time unhappy that DbUnit Express users have to create a @Before method in each test just to get the test database initialized. Fortunately since version 1.3.0 they don’t need to do it anymore thanks to JUnit Rules (if you are not familiar with them, they are an alternative to @Before/@After and @BeforeClass/@AfterClass, read this rules introduction).

As true coders you are certainly annoyed by so many words so let get to the source code.

Read the rest of this entry »

Posted in Languages, Testing | Tagged: , , | Comments Off on DRY: Use JUnit @Rule Instead of Repeating Setup/@Before in Each Test

DbUnit Express 1.3 is Even Easier to Use and Still Better

Posted by Jakub Holý on September 4, 2011

The DbUnit Express 1.3.0 (a thin wrapper around DbUnit to speed up DB testing) released today introduces features that make it even easier to write a DB unit test, the most interesting ones are the introduction of EmbeddedDbTesterRule which can automatically execute its onSetup thanks to JUnit’s @Rule (example) and the addition of setDataSet(fileName), which searches for a data set file of the given name on the classpath etc. and loads it.

See the updated project page and example tests.

Other changes of interest:

  1. The project was now officially renamed to dbunit-express (and root package changed to net.jakubholy.dbunitexpress), so update your Maven dependencies and code
  2. Upgraded to latest DbUnit (2.4.8, was 2.4.7)
  3. Added slf4j-simple to dependencies so that users don’t need to do it themselves anymore – those who don’t want it may just exclude it
  4. Added EmbeddedDbTesterRule which can call its onSetup automatically under JUnit 4
  5. Added setDataSet(String) that tries to find a file of the given name in testData/ or on the classpath and loads it
  6. When there is a FileNotFoundException for the ddl, report the working directory, check if testData/ self exists
  7. Added comment to onTearDown() saying that it does nothing and thus doesn’t need to be called, updated test classes accordingly
  8. Added SimpleNonExtendingEmbeddedDbJUnit4Test to show usage with JUnit 4
  9. When it is detected in onSetup() that the test database likely isn’t initialized, we advice to use Db Creator and report the current working directory
  10. Added method findConfigFile(name) to simplify custom DataSet creation, location of DDL files etc.
  11. Added DatabaseCreator.loadDdl(name) to load an additional DDL, you can also use new DatabaseCreator().setDdlFile(“fileOnClasspathOrInTestData.ddl”).doCreateAndInitializeTestDb() to init the DB from a custom DDL
PS: As you might have noticed, the project was migrated to GitHub because I couldn’t stand Subversion anymore. Its inability to deal with deleted folders was killing me.

Posted in Languages, Testing | Tagged: , , | Comments Off on DbUnit Express 1.3 is Even Easier to Use and Still Better