Future Plans
Esko Luontola
http://dimdwarf.sourceforge.net/) for a couple of months and it has been
working as expected: test isolation is just perfect, defer-blocks have
been a more powerful abstraction than after-blocks, adding tests is
easy, and extracting a test setup is even easier than expected.
Frankly, I haven't had any real need for adding features. That's a
promising sign that the framework is near perfection.
> "Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."
> - Antoine de Saint-Exupery
I'm expecting to make one release of Specsy which I will then use for
the next 10 years (though binary-incompatible changes to the Scala
language will probably require making releases more often).
But the feature freeze is not yet here, as I do have some plans on what
to do next. One theme is adding support for integration tests, and
another theme is porting Specsy to other JVM languages. Here are some of
my ideas:
* Using Specsy from external helper methods
I've already made a speculative change to the master branch where I
changed the visibility of the defer method to public, so that it would
be possible to call it from library code (a project-specific utility
class with helper methods for writing tests). I might also make a public
method for declaring nested specs.
Also I could add support for Scala's implicit parameters, so that the
current Spec instance would be passed implicitly to any utility methods
which are called from the tests.
* Non-isolated execution model
This has been on my TODO list since the beginning, but I haven't yet had
an actualized need for implementing it. It might be needed by
integration tests, to make the tests run faster, so I will probably add
it later. It could also be needed by specific kind of unit tests which
check multiple steps between a long process. I think I've written such
tests only once, so I should look more into the use case (it was for UI
tests which check the state of UI components after every user interaction).
* Before class & after class
I had an idea that how to implement these without disturbing the
otherwise simple execution model. The test class constructor would have
as parameter some @javax.inject.Singleton scoped concrete classes, in
which case Specsy would create one instance of it to be reused by all
test runs. If the class implements Closeable, then the close() method
would be called when all tests in the class have been executed.
In effect the constructor of the injected class would become the "before
class" code and the close() method would become the "after class" code.
* CTR4J runner & parallel execution
When I start working on CTR4J (http://groups.google.com/group/ctr4j), I
will make Specsy use it as its test runner. That will give Specsy
parallel execution for free and it will also make Specsy smaller (Specsy
would shrink from the current 570 LOC to under 300 LOC).
* Port Specsy to other JVM languages: Groovy, JRuby, Clojure... even Java!
I got an insane idea a couple of days ago. I could easily port Specsy to
work with any JVM language, with just a couple dozen lines of
language-specific wrapper code (the base class and probably also the
spec's instantiation).
Specsy's core would need to be rewritten in Java, to avoid a dependency
on the 6 MB Scala library, but that work is trivial. It wouldn't even
increase Specsy much (in LOC), because I'm not using any of Scala's
advanced features.
What makes this idea insane, is porting Specsy to Java. Specsy should be
easy to implement on any impure language which has closures. But Java
doesn't have closures, so some syntax tricks are needed. I've drafted
some proposals in
https://github.com/orfjackal/specsy/tree/41530a8560e2d2285628ed20681c1cf2056b1af0/src/test/java/net/orfjackal/specsy/examples
of which I will probably go with draft 2 and "spec" as the name for
nested specs (though it's a class, I've written it in lowercase, because
conceptually I think of it as a method call). The draft 2 is the most
verbose, but also the most expressive. Thankfully IDEs will be able to
generate the boilerplate code using code templates. So even if you are
stuck in a Java-only organization, that won't prevent you from using Specsy.
Porting to Groovy and JRuby should be very straightforward. For Groovy I
can go with similar syntax tricks as http://www.easyb.org/ does. For
JRuby I can use RSpec's syntax tricks. In both cases the keywords will
be "spec" and "defer". (See my rant
http://blog.orfjackal.net/2010/05/choice-of-words-in-testing-frameworks.html
on the choice of keywords in testing frameworks.)
Porting to Clojure might require first some more experience on using
Clojure. I've played with Clojure only very little (about two evenings -
I attended a Coding Dojo on Clojure), so I'm not yet sure that how it
would be best to declare specs in that language. Also I'm not yet
familiar with how Clojure handles mutable state, especially Clojure's
STM, and that it one of the most important things that a testing
framework must handle carefully.
These language ports, and possibly some of the above mentioned features
(unless I need them sooner), would be released as Specsy 2.0. I'll
reorganize the modules and packages, so that the Specsy wrappers for
each language are in their own Maven artifact and in their own
subpackage. That will allow the language specific parts to be developed
independenty of Specsy's core, because the programming languages will
have updates and new features more often than Specsy's stable core
libraries. Also anyone could easily create wrappers for more languages -
it requires deep knowledge the language's syntax, plus a couple dozen
lines of glue code.
--
Esko Luontola
www.orfjackal.net