Good point, I hadn't considered the output format of Specs yet. For now,
I'm going to go down the ScalaTest integration (most generic) and as a
second pass see how Specs can better be integrated. If we need two
different integrations, so be it.
alex
On Mon, May 19, 2008 at 10:28 AM, Daniel Spiewak <[EMAIL PROTECTED]>
wrote:
> Dandy! The one thing which worries me a bit is spec tests are often more
> structured than straight-up unit tests. You probably already know this
> better than I do (since Buildr uses RSpec), but it's a problem that I've run
> into trying to use Specs's JUnit integration. Running the junit:report task
> generates a completely linearized list of pass/fails. This means that you
> lose a lot of information about the test structure, especially if you have
> something like this:
>
> "my first widget" should {
> "cure world hunger" in {
> ...
> }
> }
>
> "my second widget" should {
> "cure world hunger" in {
> ...
> }
> }
>
> This just shows up as (roughly):
>
> cure world hunger : PASS
> cure world hunger : PASS
>
> If we can make the output a little more usable than this, it would be nice.
> :-) Also, Specs fails its tests by throwing an exception. I find this a
> bit annoying, but it can't be helped from their side. What would be nice is
> if the message for this exception could become the failure alert, while the
> full trace gets thrown away for brevity.
>
> ScalaTest may already handle all of this, I don't know. I do agree that
> the most elegant way to implement support would be to just write ScalaTest
> integration and trust it to do the heavy lifting. You still might want to
> have a test.using :specs invocation (or whatever is normal for the BDD
> frameworks), but behind the scenes it could use ScalaTest.
>
> Daniel
>
>
> Alex Boisvert wrote:
>
>> Hi Daniel,
>>
>> I had another look at ScalaTest, Specs and ScalaCheck this weekend;
>> didn't
>> have time enough to implement something, just gather my thoughts.
>>
>> What I have in mind now is to go for ScalaTest integration. I'd like to
>> avoid implementing the same thing 3 times, and from what I can tell, you
>> can
>> use both Specs and ScalaCheck from within ScalaTests. There's an
>> existing
>> Ant task for ScalaTest that would make the integration even more
>> lightweight
>> and consistent with what others are doing.
>>
>> (You can see how Specs and ScalaCheck are integrated at
>> http://www.artima.com/scalatest/)
>>
>> The ScalaTest integration would look essentially the same as the JUnit
>> one.
>> Run all tests, display pass/failure to stdout, send test output to
>> separate
>> files, and provide the ability to configure which suites should be run
>> (includes, excludes, based on what is currently supported by the ScalaTest
>> Ant task).
>>
>> How does that sound?
>>
>> alex
>>
>>
>> On Fri, May 16, 2008 at 3:24 PM, Daniel Spiewak<[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Are there any plans to support the Specs framework (
>>> http://specs.googlecode.com) in Buildr? Right now, the only way to make
>>> it
>>> work is to use the specs JUnit4 runner and then actually swap out the
>>> JUnit
>>> 4.3.1 JAR in your local repo with the manually-downloaded JUnit 4.4 JAR
>>> (to
>>> avoid the description error). It would be nice to see support as slick
>>> as
>>> there is for some of the other test frameworks.
>>>
>>> Daniel
>>>
>>>
>>>
>>
>>
>>
>
