Gosu and TDD

[Ricardo Mayerhofer]

Hi,
I've been playing with Gosu and found it a very interesting language. It definitely fills a gap between java and scala, congratulations on the good work!

I just miss good support for TDD/Unit testing. Considering that many developers find programming without tests as hard as programming without classes, a native test support would be a huge plus for the language. It would allow better tests expressiveness considering that it could have its own syntax, e.g.:

// GroupServiceTest.gt
"when deleting groups should delete people"
{
    groupService = new GroupService();
    groupService.delete( myGroup );
    ...
}

What do you think?

Regards,
Ricardo

[Vyktur with a Y]

Hello Ricardo,

Thanks for giving Gosu a spin! I'm glad it's filling gaps for you, as it certainly is for us.

Unfortunately for you, we at Guidewire currently have very full-featured support for TDD in-house and you don't. We're working actively to remedy that. We plan on releasing our JUnit extension as part of the Gosu package in the near future. The syntax for that would be no different from JUnit 3.

Looking at your code snippet, I admit that I don't fully follow your intent. If you're able to clarify some of the features that you'd like to see, I'm glad to lend an ear.

Cheers,

Y

--
You received this message because you are subscribed to the Google Groups "gosu-lang" group.
To post to this group, send email to gosu...@googlegroups.com.
To unsubscribe from this group, send email to gosu-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gosu-lang?hl=en.

[Gus Prevas]

Note that there's nothing really preventing you from using JUnit with Gosu out of the box; I use it extensively for Ronin.  See https://github.com/kprevas/ronin/tree/master/ronin/src-test for code that might help you.

[Vyktur with a Y]

Note that Gus' runtests.gsp does everything you would want it to in the Gosu Editor. The benefit of the stuff we're working on would be of benefit to you only in the context of an IDE like Eclipse/IntelliJ. If you're looking to get up and going quickly, try the gsp file. You can also add in some nice syntax to the run classes method by reflectively looking up your test types.

Y

[Carson Gross]

Hi Ricardo,

Glad to hear that you like Gosu.

As Gus points out, you can write tests in Gosu today using the standard java testing libraries plus a bit of scripting and, as Victor says, we are going to be releasing the library we use internally to run tests ourselves.  This library will likely ship with Gosu, so you can write tests OOTB with minimal effort.

In keeping with the general philosophy of Gosu, the library is a simplified  API on top of JUnit3 (we are anti-JUnit4 here) using more straight forward OO concepts and fewer design patterns.  More on that soon.

Regarding the custom syntax around testing, I don't expect that is something that we will be adding to Gosu (although we may support the notion of tests in our final module system.)  Gosu and JUnit3 seem to be expressive enough to succinctly express most tests, with libraries taking advantage of Gosu features filling in many of the gaps that exist in the Java testing world.

That being said, thanks to the Open Type System, there is no reason you can't explore creating a test resource with the syntax you outline below.  I wanted to add a feature called protocols to the language a while back but there wasn't unanimous support for it, so I implemented it as a type loader instead:

  http://protocols.github.com/

Your resources could have whatever syntax you think is best for expressing tests, and we can assist you in plugging in the Gosu at the points you'd like.  It would be an undertaking, but might be a lot of fun too.

Cheers,
Carson

On Tue, Mar 1, 2011 at 1:46 AM, Ricardo Mayerhofer <ricardo.e...@gmail.com> wrote:

--

[Benjamin Gudehus]

Hi,

would be nice to have something like RSpec for BDD-style testing. 

That's something I really miss in C# (although I didn't use it). They always have to use RSpec under IronRuby to develop their code BDD-style. All other solutions in C# show, that the language is accually incapable for this style of testing/specification.

Regards,

Benjamin

2011/3/1 Carson Gross <carso...@gmail.com>

[Carson Gross]

Benjamin,

Can you describe how the RSpec syntax helps?  Maybe we can try to capture some of those advantages using libraries and Gosu's syntactic abilities.

Cheers,
Carson

[Carson Gross]

Roping the rest of you guys back in to this discussion, I proposed the following syntax as a transliteration of the RSpec example Ben gave (see below) into gosu:

  function testScore() {

    using( description( Bowling#score(int), 

                                 "returns 0 for all gutter game" ) ){

      var bowling = new Bowling() 

      20.times( \-> bowling.hit(0) )

      bowling.Score.shouldEqual( 0 )

    }

  }

This would involve the following things:

* Adding a description() method to some base class that took a feature literal (the thing being tested) and returned an object compatible with the using statement.

* Adding the .times() method to Integers (I think we need a parser change to allow method invocations on primitives.)

* adding the .shouldEqual() enhancement method to, say, Object (or maybe to primitives/Strings?) via an enhancement.  (Unfortunately, in some environments we currently do not partition enhancements between modules, so this method would be considered global.  We'll fix that eventually.)

What do other people think about this?  

Cheers,
Carson

On Tue, Mar 1, 2011 at 11:48 AM, Benjamin Gudehus <hast...@googlemail.com> wrote:

Hi Carson,

1. "method/test names" can be ordinary strings. e.g. for stack the method shouldPopItemOnTop could be "should pop item on top".

2. one could nest test methods in multiple contexts. e.g. stack could have a "stack with one item" context and in it an "method" called "should pop item on top".

This way writing tests feels more as writing a testable specification.

Here are some examples in other languages. Please note that RSpec-style test are not organized in classes. I've also added an example for Spock which actually is a class and  runs in JUnit. 

=== RSpec/Ruby ===

# bowling_spec.rb

require 'bowling'

describe Bowling, "#score" do

  it "returns 0 for all gutter game" do

    bowling = Bowling.new

    20.times { bowling.hit(0) }

    bowling.score.should == 0

  end

end

=== SpecIt/QUnit/Javascript ===

describe("SpecIt", function() {

  var john, cachedItems = [];

  before(function() {

    john = {name: "John Doe", age: 26};

  });

  it("should use before blocks", function() {

    assert(john.name).should(eql, "John Doe");

    assert(john.age).should(beLessThan, 30);

  });

});

=== Spock/Groovy ===

import spock.lang.Specification

class EmptyStack extends Specification {

  def stack = new Stack()

  def "size"() {

    expect: stack.size() == 0

  }

  def "push"() {

    when:

    stack.push("elem")

    then:

    stack.size() == old(stack.size()) + 1

    stack.peek() == "elem"

  }

}

--Benjamin

2011/3/1 Carson Gross <carso...@gmail.com>

[Alan Keefer]

I'm personally not a fan of adding enhancement methods to integers
like .times(). I think it clutters up the namespace, which reduces
the value of tooling, and I think it breaks basically any sort of
reasonable OO organization scheme. Since basically anything can
involve numbers, what's the heuristic to use when deciding what
methods to add and what to leave off? Do we have 20.days.from.today?
20.ounces.converted_to.grams? 20.add_to.5? That's my personal taste,
at least. The same applies to .shouldEqual(); I have no problem with
FEST-like assertions off a helper object, but I don't like welding it
on to the object itself.

But then again, I've never found the RSpec-style that compelling
anyway, so perhaps I'm not the right person to comment in this regard.
I don't see the example Gosu code there as much of an improvement in
terms of either readability or explicitness on:

function testScoreIsZeroForAllGutterGames() {

var bowling = new Bowling()

for(i in 0..20) {
bowling.hit(0)
}
assertThat(bowling.Score).equals(0)
}

In fact, I think the using statement part of it actually makes it
harder to read. If an explicit tie to the method is necessary for the
sake of tools or something, I'd just do it in Javadoc or annotations.

But perhaps there are some other benefits to the RSpec approach that
I'm ignoring?

-Alan

[Gus Prevas]

It seems to me that the underlying philosophy of Gosu's type system is Make Stuff Look Like Dot Paths, whereas the whole point of something like RSpec is to Make Stuff Look Less Like Dot Paths, so maybe there's just a fundamental impedance mismatch here.  (I'm also not an RSpec/BDD guy, so maybe I'm off-base here.)

[JP]

Going back to junit 3 vs 4 - why are you guys anti junit 4? And what
will you do if 3 ever stops being supported?

> > On Tue, Mar 1, 2011 at 1:21 PM, Carson Gross <carsongr...@gmail.com>

> > hasteb...@googlemail.com>

> > >> 2011/3/1 Carson Gross <carsongr...@gmail.com>

>
> > >>> Benjamin,
> > >>> Can you describe how the RSpec syntax helps?  Maybe we can try to
> > capture
> > >>> some of those advantages using libraries and Gosu's syntactic
> > abilities.
>
> > >>> Cheers,
> > >>> Carson
> > >>> On Tue, Mar 1, 2011 at 11:19 AM, Benjamin Gudehus
> > >>> <hasteb...@googlemail.com> wrote:
>
> > >>>> Hi,
> > >>>> would be nice to have something like RSpec for BDD-style testing.
> > >>>> That's something I really miss in C# (although I didn't use it). They
> > >>>> always have to use RSpec under IronRuby to develop their code
> > BDD-style. All
> > >>>> other solutions in C# show, that the language is accually incapable
> > for this
> > >>>> style of testing/specification.
> > >>>> Regards,
> > >>>> Benjamin

> > >>>> 2011/3/1 Carson Gross <carsongr...@gmail.com>

> ...
>
> read more »

[Carson Gross]

Well, I won't speak for everyone, but here is my take:

* I don't think the annotations approach of JUnit4 adds much and, in fact, makes things worse in simple cases.

* JUnit4 made it easy to do some things that JUnit3 made very difficult, but did it using overly complicated APIs.  A simple inheritance model on top of the JUnit3 system (which is what the soon-to-be-released gosu testing library is) is easier to deal with and just as functional.

* Creating a Suite in JUnit4 in a general, automated way is difficult.

* JUnit is open source and functionally complete, so support isn't a huge concern for me.

JUnit3 suffered from over-design and a focus on design patterns, where a simple object model (Suite, TestClass) with reasonable methods to override at certain points in the life cycle and clear roles for classes would have been fine.

JMO, YMMV, etc.
Carson

[JP]

I can certainly see the point about the test suite, it's fairly
painful. But having "grown up" on jUnit 4, I guess I just don't know
any better :). It's a pretty clean and simple approach from my
perspective.

> ...
>
> read more »

[Ricardo Mayerhofer]

Hi, thank you all for the responses! Regarding Junit 4 I have exactly the same opinion, I even bloged about it before (http://agileenterprise.wordpress.com/2009/03/10/why-i-prefer-junit-3-over-junit-4/).
The point I raised about test syntax, is that we often use tests to document code, so having test name in string format is much more valuable than in traditional method name format.

So instead of writing:
testWhenDeletingGroupsShouldDeletePeople
{
 ...

}

We could write:
"when deleting groups should delete people"
{

    ...
}

It would be really great if we could handle this in some sort of way in Gosu.

JUnit like IDE integration is what I most miss. As soon as it become available I will migrate one of my projects.

2011/3/1 JP <johnp...@gmail.com>

> ...
>
> read more »

[Alan Keefer]

Since I don't see full details in the e-mail chain, I'll point you to
some code that lets you at least run Gosu test classes/suites in
IntelliJ (or presumably Eclipse as well), though it's a bit hacky.
It's a poor substitute, but you can get tests running in an IDE using
JUnit 4 and some customer runner/wrapper classes. Check out the
various classes in:

https://github.com/akeefer/Tosa/tree/master/tosa-test/test-src/test

and then a usage at:

https://github.com/akeefer/Tosa/blob/master/tosa-test/test-src/tosa/loader/DBTypeInfoTestWrapper.java

If you run DBTypeInfoTestWrapper in IntelliJ (I haven't tried Eclipse,
but presumably it's the same), it'll run the underlying wrapped Gosu
test. You can't run individual methods, but you can at least run the
whole test class, and if you use the Gosu plugin for IntelliJ you can
debug the Gosu code as well.

You can also run a suite of tests using something like what Carson
hacked up for the Tosa suite:

https://github.com/akeefer/Tosa/blob/master/tosa-test/test-src/test/TosaSuite.java

It's not ideal, but it's been good enough for me to at least run/debug
my tests in IntelliJ as I work on Tosa.

-Alan