Loading ...
Sorry, an error occurred while loading the content.

Re: [junit] Re: Does JUnit 4 now support dependencies?

Expand Messages
  • David Saff
    Alex, First, assumptions can go in individual test methods, or in @BeforeClass on a test class (to short-circuit many methods), or in @BeforeClass on a suite
    Message 1 of 20 , Aug 1, 2008
    View Source
    • 0 Attachment
      Alex,

      First, assumptions can go in individual test methods, or in
      @BeforeClass on a test class (to short-circuit many methods), or in
      @BeforeClass on a suite (to short-circuit the entire suite). Second,
      I assume you'd use abstraction to eliminate duplication, just like you
      do anywhere else. The advantage of having explicit method calls as
      assumptions is that you can use the abstraction mechanisms in Java to
      group assumptions, rather than having to invent a new mechanism that
      extracts sets of test description strings.

      David Saff

      On Wed, Jul 30, 2008 at 4:54 PM, toalexsmail <toalexsmail@...> wrote:
      > Hi, David!
      > I just want to understand you point. Suppose I have 200 test method in
      > 50 classes. In this class every test method should be somethiing like
      > this:
      >
      > @Test
      > public void launchMissiles() {
      > assumeTrue(A1.canLogin());
      > assumeTrue(A1.canSomethingElse());
      > ...
      > assumeTrue(A50.canSomethingCompletelyDifferent());
      >
      > launchMissiles();
      > assertFalse(enemyBase().exists());
      >
      > }
      >
      > --- In junit@yahoogroups.com, "David Saff" <david@...> wrote:
      >>
      >> Hans,
      >>
      >> There is a way of getting very close to what you want in JUnit 4.4 and
      >> beyond, with assumptions:
      >>
      >> private boolean canLogin() {
      >> // return true if login works
      >> }
      >>
      >> @Test public void login() {
      >> assertTrue(canLogin());
      >> }
      >>
      >> @Test public void launchMissiles() {
      >> assumeTrue(canLogin());
      >> launchMissiles();
      >> assertFalse(enemyBase().exists());
      >> }
      >>
      >> This is more general than test dependencies, because it allows tests
      >> to depend on conditions that are not really tested (for example, you
      >> might have tests that assume you're running on Windows). Will that
      >> work for you?
      >>
      >> David Saff
      >>
      >> On Thu, Jul 17, 2008 at 11:58 AM, Hans Schwaebli
      >> <hans_schwaebli@...> wrote:
      >> > Hi Kent,
      >> >
      >> > specifying dependencies is a little extra work, I agree. But it has
      >> > advantages.
      >> >
      >> > Consecutive tests which depend on failed tests, are not executed,
      > which
      >> > speeds up the tests. It also increases the information value.
      > People are not
      >> > confused with dozens or even hundreds of failed tests when just
      > one or two
      >> > tests really failed on which most other tests depend. I know of
      > situations
      >> > where there are dozenzs of failed tests (or more) reported by
      > CruiseControl,
      >> > and noone looks into them until one week before release date. This
      > happens.
      >> > It makes developers afraid to look into the apparent mess. If
      > there would be
      >> > just one or two failed tests, they would look into it more likely, and
      >> > sooner.
      >> >
      >> > The heuristic strategy would not really solve the problem. since
      > it is not
      >> > equivalent to the dependency specification. It would still run all
      > tests,
      >> > but the likelyhood that the first run tests are the cause for all
      > the errors
      >> > would not be very high I think, whereas you could trust the
      > dependencies
      >> > very much if they are set correctly.
      >> >
      >> > Dependencies are a frequent topic. We have it in OSGI, in issue
      > tracking
      >> > software, in project management software, in requirement
      > specifications and
      >> > in test specifications. Why not support it in JUnit tests too?
      >> >
      >> > Well, this is just some quick thoughts about it. This issue alone will
      >> > certainly not draw people to other test frameworks, but it would
      > improve
      >> > JUnit I think. Noone would be forced to use that feature, but I
      > think it
      >> > would be good, if one could use it with JUnit, even in an coarse
      > way (for
      >> > example if the dependency "testApplicationServerRuns" passed).
      >> >
      >> > Bye,
      >> >
      >> > Hans
      >> >
      >> > --- On Thu, 7/17/08, Kent Beck <kentb@...> wrote:
      >> > From: Kent Beck <kentb@...>
      >> > Subject: RE: [junit] Does JUnit 4 now support dependencies?
      >> > To: junit@yahoogroups.com
      >> > Date: Thursday, July 17, 2008, 9:28 AM
      >> >
      >> > Hans,
      >> >
      >> > I agree that test dependencies are a good idea. In my experience,
      > though,
      >> >
      >> > they aren't worth the investment to express them explicitly. I
      > would rather
      >> >
      >> > put the same time into improving the design of the software so the
      > tests can
      >> >
      >> > run fast.
      >> >
      >> > I wonder if it would be possible to infer dependencies from
      > historical data,
      >> >
      >> > though. That and the "most recently broken first" heuristic might
      > provide
      >> >
      >> > nearly optimal "time to first failure", which I assume is your goal in
      >> >
      >> > wishing for dependencies.
      >> >
      >> > Regards,
      >> >
      >> > Kent Beck
      >> >
      >> > Three Rivers Institute
      >> >
      >> > _____
      >> >
      >> > From: junit@yahoogroups. com [mailto:junit@yahoogroups. com] On
      > Behalf Of
      >> >
      >> > hans_schwaebli
      >> >
      >> > Sent: Wednesday, July 16, 2008 5:58 AM
      >> >
      >> > To: junit@yahoogroups. com
      >> >
      >> > Subject: [junit] Does JUnit 4 now support dependencies?
      >> >
      >> > I now think that test dependencies are a good idea.
      >> >
      >> > Does JUnit 4.x support such dependencies, or if not, is it planned for
      >> >
      >> > a certain JUnit release to be added?
      >> >
      >> > For example, if the login test did not work, than all other tests
      >> >
      >> > cannot work. They depend on the login test. If login test fails, the
      >> >
      >> > other tests are not executed.
      >> >
      >> > [Non-text portions of this message have been removed]
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> > [Non-text portions of this message have been removed]
      >> >
      >> >
      >>
      >
      >
    • David Saff
      On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli ... Given that boolean canLogin() exists, I see a one-line difference between public static boolean CAN_LOGIN
      Message 2 of 20 , Aug 1, 2008
      View Source
      • 0 Attachment
        On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli
        <hans_schwaebli@...> wrote:
        > I would see this as a workaround.
        >
        > As I said, dependencies are a frequent and often important issue in
        > organisation of various things (lets be general). So a direct support by
        > JUnit for dependencies out of the box would be ideal I think.
        >
        > In your example I would need to store the result of canLogin () into a
        > global variable. Otherwise the canLogin-test would be executed multiple
        > times if canLogin() dependency is needed in more than one test. This is what
        > a framework like JUnit could do more productively and correctly than a
        > programmer.

        Given that "boolean canLogin()" exists, I see a one-line difference between

        public static boolean CAN_LOGIN = canLogin();
        @Test public void myTest() {
        assumeTrue(CAN_LOGIN);

        and

        @DependsOn("nett.saff.myprogram.LoginTests.canLogin");
        @Test public void myTest() {

        For that one line, you get static checking and refactoring support
        (did you notice the typo in "nett"?)

        I'd love it if you could give the assumption framework a try, and
        JExample, and report back your experiences. I fear otherwise, we're
        trading in hypotheticals. Thanks,

        David
      • Cédric Beust ♔
        This approach doesn t scale as soon as you need to depend on more than one method (what do you do later down the road when you need to add one method to the
        Message 3 of 20 , Aug 1, 2008
        View Source
        • 0 Attachment
          This approach doesn't scale as soon as you need to depend on more than one
          method (what do you do later down the road when you need to add one method
          to the dependencies? Update all the methods that depend on it?), which is
          why I introduced groups in TestNG...

          --
          Cédric


          On Fri, Aug 1, 2008 at 7:26 AM, David Saff <david@...> wrote:

          > On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli
          >
          > <hans_schwaebli@... <hans_schwaebli%40yahoo.com>> wrote:
          > > I would see this as a workaround.
          > >
          > > As I said, dependencies are a frequent and often important issue in
          > > organisation of various things (lets be general). So a direct support by
          > > JUnit for dependencies out of the box would be ideal I think.
          > >
          > > In your example I would need to store the result of canLogin () into a
          > > global variable. Otherwise the canLogin-test would be executed multiple
          > > times if canLogin() dependency is needed in more than one test. This is
          > what
          > > a framework like JUnit could do more productively and correctly than a
          > > programmer.
          >
          > Given that "boolean canLogin()" exists, I see a one-line difference between
          >
          > public static boolean CAN_LOGIN = canLogin();
          > @Test public void myTest() {
          > assumeTrue(CAN_LOGIN);
          >
          > and
          >
          > @DependsOn("nett.saff.myprogram.LoginTests.canLogin");
          > @Test public void myTest() {
          >
          > For that one line, you get static checking and refactoring support
          > (did you notice the typo in "nett"?)
          >
          > I'd love it if you could give the assumption framework a try, and
          > JExample, and report back your experiences. I fear otherwise, we're
          > trading in hypotheticals. Thanks,
          >
          > David
          >
          >


          [Non-text portions of this message have been removed]
        • David Saff
          If I had a bunch of methods depending on canLogin(), and then discovered that all of those methods also depended on answering a captcha, I would use my IDE to
          Message 4 of 20 , Aug 1, 2008
          View Source
          • 0 Attachment
            If I had a bunch of methods depending on canLogin(), and then
            discovered that all of those methods also depended on answering a
            captcha, I would use my IDE to rename canLogin() to
            canLoginAndAnswerCaptcha(), and add the new check to that method.
            Wouldn't you?

            David Saff

            On Fri, Aug 1, 2008 at 12:05 PM, Cédric Beust ♔ <cbeust@...> wrote:
            > This approach doesn't scale as soon as you need to depend on more than one
            > method (what do you do later down the road when you need to add one method
            > to the dependencies? Update all the methods that depend on it?), which is
            > why I introduced groups in TestNG...
            >
            > --
            > Cédric
            >
            > On Fri, Aug 1, 2008 at 7:26 AM, David Saff <david@...> wrote:
            >
            >> On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli
            >>
            >> <hans_schwaebli@... <hans_schwaebli%40yahoo.com>> wrote:
            >> > I would see this as a workaround.
            >> >
            >> > As I said, dependencies are a frequent and often important issue in
            >> > organisation of various things (lets be general). So a direct support by
            >> > JUnit for dependencies out of the box would be ideal I think.
            >> >
            >> > In your example I would need to store the result of canLogin () into a
            >> > global variable. Otherwise the canLogin-test would be executed multiple
            >> > times if canLogin() dependency is needed in more than one test. This is
            >> what
            >> > a framework like JUnit could do more productively and correctly than a
            >> > programmer.
            >>
            >> Given that "boolean canLogin()" exists, I see a one-line difference
            >> between
            >>
            >> public static boolean CAN_LOGIN = canLogin();
            >> @Test public void myTest() {
            >> assumeTrue(CAN_LOGIN);
            >>
            >> and
            >>
            >> @DependsOn("nett.saff.myprogram.LoginTests.canLogin");
            >> @Test public void myTest() {
            >>
            >> For that one line, you get static checking and refactoring support
            >> (did you notice the typo in "nett"?)
            >>
            >> I'd love it if you could give the assumption framework a try, and
            >> JExample, and report back your experiences. I fear otherwise, we're
            >> trading in hypotheticals. Thanks,
            >>
            >> David
            >>
            >>
            >
            > [Non-text portions of this message have been removed]
            >
            >
          • Cédric Beust ♔
            Consider this: testServlet1() { assume(canLogin()); } testServlet2() { assume(canLogin()); } And you want to add another dependency, say serverStarted() . Now
            Message 5 of 20 , Aug 1, 2008
            View Source
            • 0 Attachment
              Consider this:

              testServlet1() {
              assume(canLogin());
              }

              testServlet2() {
              assume(canLogin());
              }

              And you want to add another dependency, say "serverStarted()".

              Now you have to find all the methods that depend on the server and add the
              correct assume (manually):

              testServlet1() {
              assume(serverStarted());
              assume(canLogin());
              }

              testServlet2() {
              assume(serverStarted());
              assume(canLogin());
              }

              This is what I mean when I say that this approach doesn't scale.

              Contrast this with groups:

              @Test(groups = "init")
              public void canLogin() { .. }

              @Test(dependsOnGroups = "init")
              public void testServlet1() { ... }

              @Test(dependsOnGroups = "init")
              public void testServlet2() { ... }

              Now you want to add serverStarted() as a dependency, you only need to create
              that method and put it in the group "init":

              @Test(groups = "init")
              public void serverStarted() { ... }

              and TestNG will automatically run both serverStarted() and canLogin() before
              running any method that depends on the group "init".

              --
              Cédric



              On Fri, Aug 1, 2008 at 9:58 AM, David Saff <david@...> wrote:

              > If I had a bunch of methods depending on canLogin(), and then
              > discovered that all of those methods also depended on answering a
              > captcha, I would use my IDE to rename canLogin() to
              > canLoginAndAnswerCaptcha(), and add the new check to that method.
              > Wouldn't you?
              >




              >
              >
              > David Saff
              >
              >
              > On Fri, Aug 1, 2008 at 12:05 PM, Cédric Beust ♔ <cbeust@...<cbeust%40google.com>>
              > wrote:
              > > This approach doesn't scale as soon as you need to depend on more than
              > one
              > > method (what do you do later down the road when you need to add one
              > method
              > > to the dependencies? Update all the methods that depend on it?), which is
              > > why I introduced groups in TestNG...
              > >
              > > --
              > > Cédric
              > >
              > > On Fri, Aug 1, 2008 at 7:26 AM, David Saff <david@...<david%40saff.net>>
              > wrote:
              > >
              > >> On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli
              > >>
              > >> <hans_schwaebli@... <hans_schwaebli%40yahoo.com> <hans_schwaebli%
              > 40yahoo.com>> wrote:
              > >> > I would see this as a workaround.
              > >> >
              > >> > As I said, dependencies are a frequent and often important issue in
              > >> > organisation of various things (lets be general). So a direct support
              > by
              > >> > JUnit for dependencies out of the box would be ideal I think.
              > >> >
              > >> > In your example I would need to store the result of canLogin () into a
              > >> > global variable. Otherwise the canLogin-test would be executed
              > multiple
              > >> > times if canLogin() dependency is needed in more than one test. This
              > is
              > >> what
              > >> > a framework like JUnit could do more productively and correctly than a
              > >> > programmer.
              > >>
              > >> Given that "boolean canLogin()" exists, I see a one-line difference
              > >> between
              > >>
              > >> public static boolean CAN_LOGIN = canLogin();
              > >> @Test public void myTest() {
              > >> assumeTrue(CAN_LOGIN);
              > >>
              > >> and
              > >>
              > >> @DependsOn("nett.saff.myprogram.LoginTests.canLogin");
              > >> @Test public void myTest() {
              > >>
              > >> For that one line, you get static checking and refactoring support
              > >> (did you notice the typo in "nett"?)
              > >>
              > >> I'd love it if you could give the assumption framework a try, and
              > >> JExample, and report back your experiences. I fear otherwise, we're
              > >> trading in hypotheticals. Thanks,
              > >>
              > >> David
              > >>
              > >>
              > >
              > > [Non-text portions of this message have been removed]
              > >
              > >
              >
              >


              [Non-text portions of this message have been removed]
            • David Saff
              ... I assert that I can automatically add a line to canLogin, and rename it, and end up with: testServlet1() { assumeTrue(serverStartedAndCanLogin()); }
              Message 6 of 20 , Aug 1, 2008
              View Source
              • 0 Attachment
                On Fri, Aug 1, 2008 at 1:24 PM, Cédric Beust ♔ <cbeust@...> wrote:
                > Consider this:
                >
                > testServlet1() {
                > assume(canLogin());
                > }
                >
                > testServlet2() {
                > assume(canLogin());
                > }
                >
                > And you want to add another dependency, say "serverStarted()".
                >
                > Now you have to find all the methods that depend on the server and add the
                > correct assume (manually):
                >
                > testServlet1() {
                > assume(serverStarted());
                > assume(canLogin());
                > }
                >
                > testServlet2() {
                > assume(serverStarted());
                > assume(canLogin());
                > }

                I assert that I can automatically add a line to canLogin, and rename
                it, and end up with:

                testServlet1() {
                assumeTrue(serverStartedAndCanLogin());
                }

                testServlet2() {
                assumeTrue(serverStartedAndCanLogin());
                }

                If, as seems likely, you can't login if the server isn't started, I
                can even skip the rename step. Am I missing something deep about this
                scaling problem, or is this a matter of preference?

                David Saff
              • Alex Ruiz
                +1 test groups IMHO, test groups are a lot more refactoring-friendly than method names. For example, I use the following class to specify all my test groups:
                Message 7 of 20 , Aug 1, 2008
                View Source
                • 0 Attachment
                  +1 test groups

                  IMHO, test groups are a lot more
                  "refactoring-friendly" than method names. For example,
                  I use the following class to specify all my test
                  groups:

                  public class TestGroups {
                  public static final String GUI = "GUI";
                  public static final String BUG = "Bug";
                  }


                  In my test:

                  @Test(groups=TestGroups.GUI)
                  public void shouldDoSomethingNice() {
                  // test implementation
                  }

                  with this approach I take advantage of my IDE to
                  easily find usages of the constant TestGroups.GUI. It
                  is pretty simple to rename the constant or change its
                  value.

                  On the other hand, in a previous e-mail in this thread
                  the following was said:

                  > @DependsOn(" nett.saff. myprogram. LoginTests.
                  canLogin" );
                  > @Test public void myTest() {
                  >
                  > For that one line, you get static checking and
                  refactoring support
                  > (did you notice the typo in "nett"?)

                  Again, IMHO, there is no static checking because the
                  FQN of the method is a String. There is a run-time
                  checking though, but my IDE cannot tell me about the
                  typo. There is no refactoring support either, only
                  "find and replace" based on Strings, which can be
                  error prone depending on the case.

                  Regards,
                  -Alex




                  --- Cédric Beust ♔ <cbeust@...> wrote:

                  > Consider this:
                  >
                  > testServlet1() {
                  > assume(canLogin());
                  > }
                  >
                  > testServlet2() {
                  > assume(canLogin());
                  > }
                  >
                  > And you want to add another dependency, say
                  > "serverStarted()".
                  >
                  > Now you have to find all the methods that depend on
                  > the server and add the
                  > correct assume (manually):
                  >
                  > testServlet1() {
                  > assume(serverStarted());
                  > assume(canLogin());
                  > }
                  >
                  > testServlet2() {
                  > assume(serverStarted());
                  > assume(canLogin());
                  > }
                  >
                  > This is what I mean when I say that this approach
                  > doesn't scale.
                  >
                  > Contrast this with groups:
                  >
                  > @Test(groups = "init")
                  > public void canLogin() { .. }
                  >
                  > @Test(dependsOnGroups = "init")
                  > public void testServlet1() { ... }
                  >
                  > @Test(dependsOnGroups = "init")
                  > public void testServlet2() { ... }
                  >
                  > Now you want to add serverStarted() as a dependency,
                  > you only need to create
                  > that method and put it in the group "init":
                  >
                  > @Test(groups = "init")
                  > public void serverStarted() { ... }
                  >
                  > and TestNG will automatically run both
                  > serverStarted() and canLogin() before
                  > running any method that depends on the group "init".
                  >
                  > --
                  > Cédric
                  >
                  >
                  >
                  > On Fri, Aug 1, 2008 at 9:58 AM, David Saff
                  > <david@...> wrote:
                  >
                  > > If I had a bunch of methods depending on
                  > canLogin(), and then
                  > > discovered that all of those methods also depended
                  > on answering a
                  > > captcha, I would use my IDE to rename canLogin()
                  > to
                  > > canLoginAndAnswerCaptcha(), and add the new check
                  > to that method.
                  > > Wouldn't you?
                  > >
                  >
                  >
                  >
                  >
                  > >
                  > >
                  > > David Saff
                  > >
                  > >
                  > > On Fri, Aug 1, 2008 at 12:05 PM, Cédric Beust ♔
                  > <cbeust@...<cbeust%40google.com>>
                  > > wrote:
                  > > > This approach doesn't scale as soon as you need
                  > to depend on more than
                  > > one
                  > > > method (what do you do later down the road when
                  > you need to add one
                  > > method
                  > > > to the dependencies? Update all the methods that
                  > depend on it?), which is
                  > > > why I introduced groups in TestNG...
                  > > >
                  > > > --
                  > > > Cédric
                  > > >
                  > > > On Fri, Aug 1, 2008 at 7:26 AM, David Saff
                  > <david@...<david%40saff.net>>
                  > > wrote:
                  > > >
                  > > >> On Thu, Jul 31, 2008 at 3:46 AM, Hans Schwaebli
                  > > >>
                  > > >> <hans_schwaebli@...
                  > <hans_schwaebli%40yahoo.com> <hans_schwaebli%
                  > > 40yahoo.com>> wrote:
                  > > >> > I would see this as a workaround.
                  > > >> >
                  > > >> > As I said, dependencies are a frequent and
                  > often important issue in
                  > > >> > organisation of various things (lets be
                  > general). So a direct support
                  > > by
                  > > >> > JUnit for dependencies out of the box would
                  > be ideal I think.
                  > > >> >
                  > > >> > In your example I would need to store the
                  > result of canLogin () into a
                  > > >> > global variable. Otherwise the canLogin-test
                  > would be executed
                  > > multiple
                  > > >> > times if canLogin() dependency is needed in
                  > more than one test. This
                  > > is
                  > > >> what
                  > > >> > a framework like JUnit could do more
                  > productively and correctly than a
                  > > >> > programmer.
                  > > >>
                  > > >> Given that "boolean canLogin()" exists, I see a
                  > one-line difference
                  > > >> between
                  > > >>
                  > > >> public static boolean CAN_LOGIN = canLogin();
                  > > >> @Test public void myTest() {
                  > > >> assumeTrue(CAN_LOGIN);
                  > > >>
                  > > >> and
                  > > >>
                  > > >>
                  >
                  @DependsOn("nett.saff.myprogram.LoginTests.canLogin");
                  > > >> @Test public void myTest() {
                  > > >>
                  > > >> For that one line, you get static checking and
                  > refactoring support
                  > > >> (did you notice the typo in "nett"?)
                  > > >>
                  > > >> I'd love it if you could give the assumption
                  > framework a try, and
                  > > >> JExample, and report back your experiences. I
                  > fear otherwise, we're
                  > > >> trading in hypotheticals. Thanks,
                  > > >>
                  > > >> David
                  > > >>
                  > > >>
                  > > >
                  > > > [Non-text portions of this message have been
                  > removed]
                  > > >
                  > > >
                  > >
                  > >
                  >
                  >
                  > [Non-text portions of this message have been
                  > removed]
                  >
                  >
                • adrian.kuhn
                  If you check out JExample, please make sure to use the latest revision (I have fixed a lot of bugs recently and improved the method references syntax...)
                  Message 8 of 20 , Aug 11, 2008
                  View Source
                  • 0 Attachment
                    If you check out JExample, please make sure to use the latest revision (I have fixed a lot of
                    bugs recently and improved the method references syntax...)

                    http://smallwiki.unibe.ch/JExample

                    cheers,
                    AA

                    --- In junit@yahoogroups.com, "David Saff" <david@...> wrote:
                    > I'd love it if you could give the assumption framework a try, and
                    > JExample, and report back your experiences. I fear otherwise, we're
                    > trading in hypotheticals. Thanks,
                    >
                    > David
                    >
                  • Hans Schwaebli
                    Looks interesting. Its pretty clear to me now that using dependencies in test cases is a good thing. I still hope the JUnit architects will be convinced of
                    Message 9 of 20 , Aug 20, 2008
                    View Source
                    • 0 Attachment
                      Looks interesting. Its pretty clear to me now that using dependencies in test cases is a good thing. I still hope the JUnit architects will be convinced of this one day.

                      But we have still to use JUnit 3.8.1.

                      Can you make JExample compatible for JUnit 3.8.x?



                      --- On Mon, 8/11/08, adrian.kuhn <adrian.kuhn@...> wrote:
                      From: adrian.kuhn <adrian.kuhn@...>
                      Subject: [junit] Re: Does JUnit 4 now support dependencies?
                      To: junit@yahoogroups.com
                      Date: Monday, August 11, 2008, 11:28 AM











                      If you check out JExample, please make sure to use the latest revision (I have fixed a lot of

                      bugs recently and improved the method references syntax...)



                      http://smallwiki. unibe.ch/ JExample



                      cheers,

                      AA



                      --- In junit@yahoogroups. com, "David Saff" <david@...> wrote:

                      > I'd love it if you could give the assumption framework a try, and

                      > JExample, and report back your experiences. I fear otherwise, we're

                      > trading in hypotheticals. Thanks,

                      >

                      > David

                      >





























                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.