On Wed, Mar 11, 2009 at 1:55 AM, etorreborre <etorrebo...@gmail.com> wrote:
> Knowing that you can write specs which can be run as JUnit tests,
> can't the "continuous testing" plugin in Eclipse work with that?
I'm using Eclipse 3.4 and neither ct-eclipse nor the MIT continuous testing
tools seem to work on that platform anymore (neither of them appear to be
maintained anymore).
Or would you like something simple like autotest in Ruby which polls
> the modified files regularly and executes the tests in the console if
> any file is modified? I've just seen someone creating a FilePoller in
> Scala. I could certainly make a good use of it then.
Continuous polling I can do with Buildr... but it wastes a lot of cycles
because it's not smart about what to re-test and ideally I'd like to get the
error reporting directly in Eclipse, in a different tab such as the
compilation error tab.
> BTW, the next version of specs allows you to mix-in a JUnit trait (or
> ScalaTest) to a Specification like this:
>
> class mySpec extends Specification with JUnit { ... }
>
> The only difference with before is that your specification has to be a
> class. And in that case, if you want to execute it in the console you
> need to do:
>
> // if mySpec is a class, the "run" class can be used to execute it
> java -cp ... run org.mypackage.mySpec
Interesting. I thought having specs as objects was good design by default.
I don't usually design my specs to be extensible/reusable, so for me it made
sense to have them as objects. I don't have an issue about making them
classes if they are meant to be subclassed, although I seldom have this need
myself. Maybe when I'll start using the cake pattern in tests...
One more thing to note, if you're a Maven user (I don't remember how
> Buildr does it), you have to be careful about the Specification class
> naming because by default only **/*Test files are included. I recently
> made sure that all my Specifications in the project were named xxxSpec
> and xxxxUnit, and I configured Maven to execute only those.
Similar thing for Buildr... we use naming conventions for now since it's
less fragile than doing introspection (but more error-prone from a user's
perspective).
alex
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
