High Level Testing with a High Level Language
Join the DZone community and get the full member experience.
Join For FreeIn the early days of my project we made the decision to high-level test
our Java application with Clojure*. One and a half years later, we're
still following that path. It seemed worthwhile to document the
progress so far.
My current preferred style of testing is rigorous unit testing and less than a dozen high level tests.
This style of testing doesn't catch everything; however, context is king.
In my context, we constantly have to balance the number of bugs against
the speed at which we deliver. We could test more, but it would slow
down delivery. Since we don't want to drastically impact delivery, we
try to get the most we can out of the tests that we do write.
A
few more notes on context. Our high level tests are written by
programmers for programmers. The application is fairly large and
complex. We use Java, Clojure, Ruby, C#, & others. We take
advantage of open-source frameworks as well as vendor and in-house
frameworks. The result is a user-facing application used exclusively
in-house. It's not a service or a 'for-sale' product.
The Bad
Context:
The team knows Java fairly well and writes the majority of the domain
code in Java. The team didn't have any previous experience with
Clojure.
Result: Happiness with using a high level language was often impacted by no knowledge of that high level language.
Context: The vast majority of the code is written in Java and is able to be manipulated with IntelliJ.
Result:
Some members of the team felt that using an additional language
hampered their ability to use automated refactoring tools, and thus the
rewards were not worth the cost. Other members believe the powerful
language features provide benefits that out-weigh the costs.
Context:
The tests need to run on developer boxes and build machines. One and a
half years ago, there was no easy way to run Clojure tests in JUnit.
Result:
The team hacked together something custom. It didn't take long to
write, but the integration with IntelliJ and JUnit is not nearly as
nice as using pure Java.
The Interesting
Context:
The team has plenty of experience with Object Oriented (OO) based,
C-style languages. The team didn't have any previous experience with
Functional Programming (FP). Tests are procedural. However, the team was much more experienced writing procedural code in OO than FP.
Result:
The paradigm shift impacted the speed at which the team was able to
learn Clojure, but the team was able to peek into the world of FP
without writing an entire application using an FP language.
The Good
Context: The team needed to build several utilities that allowed them to high level test the application.
Result: It was trivial to create a REPL
that allowed us to communicate at a high level with our application. We
practically got a command line interface to our application for free.
Context:
The team was curious if Clojure would be the right language for solving
other problems on the project. The team knew that with less than a
dozen high level tests, rewriting the tests in another language would
not be a large time investment.
Result:
The team was able to determine that Clojure is a viable language choice
for several tasks without having to take the leap on a mission critical
component whose size may be variable.
Context:
High level tests often require a significant amount of setup code.
Clojure provides language features (duck-typing, macros, etc) that
allow you to reduce the noise often generated by setup code.
Result:
The tests are easier to read and maintain (assuming you understand what
and how things are being hidden) and the amount of utility code
required to run high level tests was significantly reduced.
*We still use Java to unit test our Java, for now.
From http://blog.jayfields.com/2010/07/high-level-testing-with-high-level.html
Opinions expressed by DZone contributors are their own.
Comments