junit-devel — junit developers

Re: [Junit-devel] Junit4 -Backward compatibility

[Sajeev V. <saj...@ho...>]

David,
 
Thanks for your reply. Appriciate your time.
 
what do you mean by
 
>>
Is continuing to link against the legacy jar an option?
I want to use latest Junit4.jar  compile my existing framework  and start writing new tests in Junit 4 style. In short I want to 1)Maintain my Legacy test framework which uses Junit3.82)Replace this with Junit4 jar and start writing tests in Junit4 style.3)Run my  Junit4 tests as explained below using our legacy frameworkhttp://sqa.fyicenter.com/FAQ/JUnit/How_to_Run_Your_JUnit_4_4_Tests_with_a_JUnit_3_8.html 4)In short maintain old and new style Junit tests in the same framework. thanksSajeev 
 Date: Fri, 7 Nov 2014 09:56:35 -0500
Subject: Re: [Junit-devel] Junit4 -Backward compatibility
From: da...@sa...
To: saj...@ho...; ju...@ya...
CC: jun...@li...

[+junit-users]
Sajeev,
The classes you reference in that link (StandardTestSuiteLoader , TestSuiteLoader) were removed in JUnit 4.0; they were part of the standalone JUnit runner UI, which was removed in 4.0.
Is continuing to link against the legacy jar an option?
   David
On Fri, Nov 7, 2014 at 12:28 AM, Sajeev Vela <saj...@ho...> wrote:



Dear Dev Members,

I am stuck with Junit backward compatibility problem.

Please help me. Appreciate your time.

I have posed my query here in stackoverflow no luck so far.



http://stackoverflow.com/questions/26756416/junit-4-backward-compatibiliy 


 		 	   		  

------------------------------------------------------------------------------


_______________________________________________

Junit-devel mailing list

Jun...@li...

https://lists.sourceforge.net/lists/listinfo/junit-devel



 		 	   		  

Re: [Junit-devel] Junit4 -Backward compatibility

[David S. <da...@sa...>]

[+junit-users]

Sajeev,

The classes you reference in that link (StandardTestSuiteLoader ,
TestSuiteLoader) were removed in JUnit 4.0; they were part of the
standalone JUnit runner UI, which was removed in 4.0.

Is continuing to link against the legacy jar an option?

   David

On Fri, Nov 7, 2014 at 12:28 AM, Sajeev Vela <saj...@ho...>
wrote:

> Dear Dev Members,
>
> I am stuck with Junit backward compatibility problem.
>
> Please help me.
>
> I have posed my query here in stackoverflow no luck so far.
>
>
> <http://stackoverflow.com/questions/26756416/junit-4-backward-compatibiliy>
> http://stackoverflow.com/questions/26756416/junit-4-backward-compatibiliy
>
>
>
> Appreciate your time.
>
>
> Regards
>
> Archana
>
>
> <http://stackoverflow.com/questions/26756416/junit-4-backward-compatibiliy>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

[Junit-devel] Junit4 -Backward compatibility

[Sajeev V. <saj...@ho...>]

Dear Dev Members,

I am stuck with Junit backward compatibility problem.

Please help me.

I have posed my query here in stackoverflow no luck so far.



http://stackoverflow.com/questions/26756416/junit-4-backward-compatibiliy

Appreciate your time.
RegardsArchana




 		 	   		  

Re: [Junit-devel] Generating the project site via Maven. GitHub Pull Request 787

[Stephen C. <ste...@gm...>]

On 10 January 2014 15:58, Stephen Connolly
<ste...@gm...>wrote:

>  carousel
>

http://www.youtube.com/watch?v=suRDUFpsHus

Re: [Junit-devel] Generating the project site via Maven. GitHub Pull Request 787

[Stephen C. <ste...@gm...>]

The tour is defined at
https://github.com/stephenc/junit/blob/generate-site/src/site/xdoc/index.xml#L136

All that is needed for a tour is that the page have the hopscotch css and
js loaded and you have a <script> defining the tour, because a cookie is
used to hold the tour state you can span multiple pages on the same site if
you want to.

(really like the hopscotch component BTW in case you haven't noticed!)


On 10 January 2014 15:58, Stephen Connolly
<ste...@gm...>wrote:

> You can add as many examples to the carousel as you want... it's just a
> question of writing the content:
> https://github.com/stephenc/junit/blob/generate-site/src/site/xdoc/index.xml#L20
>
> I just put enough placeholders so that people could understand what can be
> done and how to do it... I could get more fancy... but I think a carousel
> and a tour is plenty! (some might say too much)
>
> also, the tour can span multiple pages, but those pages need to be written
> in the xdoc format... I am looking into adding support to doxia to allow
> markdown pages to have the required support.
>
>
> On 10 January 2014 15:44, Kevin Cooney <kc...@go...> wrote:
>
>> Wow. Very nice. Would live to see more example code at the top (Rules?
>> Theories?)
>>
>> What's up with the red splotches after the links?
>>
>> I know very little about maven. Do any of the "regulars" that do JUnit
>> code reviews know much about Maven?
>> On Jan 10, 2014 6:24 AM, "Stephen Connolly" <
>> ste...@gm...> wrote:
>>
>>> https://github.com/junit-team/junit/pull/787
>>>
>>> Just an FYI, so that you can see how this would look, I have pushed to a
>>> gh-pages on my fork...
>>>
>>> http://stephenc.github.io/junit/
>>>
>>> Obviously I have just put some placeholder content in... but let me know
>>> what you think!
>>>
>>> -Stephen
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Junit-devel mailing list
>>> Jun...@li...
>>> https://lists.sourceforge.net/lists/listinfo/junit-devel
>>>
>>>
>

Re: [Junit-devel] Generating the project site via Maven. GitHub Pull Request 787

[Stephen C. <ste...@gm...>]

You can add as many examples to the carousel as you want... it's just a
question of writing the content:
https://github.com/stephenc/junit/blob/generate-site/src/site/xdoc/index.xml#L20

I just put enough placeholders so that people could understand what can be
done and how to do it... I could get more fancy... but I think a carousel
and a tour is plenty! (some might say too much)

also, the tour can span multiple pages, but those pages need to be written
in the xdoc format... I am looking into adding support to doxia to allow
markdown pages to have the required support.


On 10 January 2014 15:44, Kevin Cooney <kc...@go...> wrote:

> Wow. Very nice. Would live to see more example code at the top (Rules?
> Theories?)
>
> What's up with the red splotches after the links?
>
> I know very little about maven. Do any of the "regulars" that do JUnit
> code reviews know much about Maven?
> On Jan 10, 2014 6:24 AM, "Stephen Connolly" <
> ste...@gm...> wrote:
>
>> https://github.com/junit-team/junit/pull/787
>>
>> Just an FYI, so that you can see how this would look, I have pushed to a
>> gh-pages on my fork...
>>
>> http://stephenc.github.io/junit/
>>
>> Obviously I have just put some placeholder content in... but let me know
>> what you think!
>>
>> -Stephen
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Junit-devel mailing list
>> Jun...@li...
>> https://lists.sourceforge.net/lists/listinfo/junit-devel
>>
>>

Re: [Junit-devel] Generating the project site via Maven. GitHub Pull Request 787

[Kevin C. <kc...@go...>]

Wow. Very nice. Would live to see more example code at the top (Rules?
Theories?)

What's up with the red splotches after the links?

I know very little about maven. Do any of the "regulars" that do JUnit code
reviews know much about Maven?
On Jan 10, 2014 6:24 AM, "Stephen Connolly" <ste...@gm...>
wrote:

> https://github.com/junit-team/junit/pull/787
>
> Just an FYI, so that you can see how this would look, I have pushed to a
> gh-pages on my fork...
>
> http://stephenc.github.io/junit/
>
> Obviously I have just put some placeholder content in... but let me know
> what you think!
>
> -Stephen
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

[Junit-devel] Generating the project site via Maven. GitHub Pull Request 787

[Stephen C. <ste...@gm...>]

https://github.com/junit-team/junit/pull/787

Just an FYI, so that you can see how this would look, I have pushed to a
gh-pages on my fork...

http://stephenc.github.io/junit/

Obviously I have just put some placeholder content in... but let me know
what you think!

-Stephen

Re: [Junit-devel] filtering tests via annotations

[David S. <da...@sa...>]

Paul,

One good thing would be for you to potentially weigh in on this proposed
patch:

https://github.com/junit-team/junit/pull/647

That's proposing a single string-based syntax for describing filters to be
applied to a test request.  Ideally, your proposal could adapt to this
interface, and be released as a library that anyone could pick up and use
regardless of whether they're running maven or Eclipse or whatever.

Otherwise, I don't think this list any longer reaches most of the people
involved in day-to-day development and maintenance, so you may want to try
again on ju...@ya....

Thanks,

   David

On Fri, Mar 22, 2013 at 2:31 PM, Paul Sprague <spr...@gm...> wrote:

> I've coded a patch to the maven surefire plugin which allows for filtering
> tests classes based on arbitrary class level annotations when using junit.
>
> The patch is attached to the jira here:
> https://jira.codehaus.org/browse/SUREFIRE-833#comment-322466
> There is also an example of how it works in the comments section.
>
> I've been asked to reach out to this mailing list concerning this change.
> I think at issue is the question of who is responsible for this type of
> filtering; should this type of functionality be part of junit?
>
> Thanks,
> Paul
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

Re: [Junit-devel] filtering tests via annotations

[Kevin C. <kc...@go...>]

I'm not in a place to make a decision either way, but it seems strange to
me to have a way to use annotations to specify categories that will work
with the Maven Surefire plugin but not in IDEs.

-- Kevin

On Fri, Mar 22, 2013 at 11:31 AM, Paul Sprague <spr...@gm...> wrote:

> I've coded a patch to the maven surefire plugin which allows for filtering
> tests classes based on arbitrary class level annotations when using junit.
>
> The patch is attached to the jira here:
> https://jira.codehaus.org/browse/SUREFIRE-833#comment-322466
> There is also an example of how it works in the comments section.
>
> I've been asked to reach out to this mailing list concerning this change.
> I think at issue is the question of who is responsible for this type of
> filtering; should this type of functionality be part of junit?
>
> Thanks,
> Paul
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

[Junit-devel] filtering tests via annotations

[Paul S. <spr...@gm...>]

I've coded a patch to the maven surefire plugin which allows for filtering
tests classes based on arbitrary class level annotations when using junit.

The patch is attached to the jira here:
https://jira.codehaus.org/browse/SUREFIRE-833#comment-322466
There is also an example of how it works in the comments section.

I've been asked to reach out to this mailing list concerning this change. I
think at issue is the question of who is responsible for this type of
filtering; should this type of functionality be part of junit?

Thanks,
Paul

[Junit-devel] (no subject)

[Luckson K. <luc...@gm...>]

Luckson Karikoga,

Cell: +27 844 724 897 (South Africa)

[Junit-devel] xDD projects survey

[<nic...@gm...>]

If you have trouble viewing or submitting this form, you can fill it out  
online:
https://docs.google.com/spreadsheet/viewform?formkey=dDlpdS1Fb3pGU3Z5YTlVT28wcDZpd0E6MQ


xDD projects survey


Hi, my name is Nicolás Dascanio and i'm doing my software engenieering  
thesis on TDD and ATDD. My native language is not english, so I apologize  
for any mistake this survey may have. I'm looking for projects devoloped  
with xDD and i'm asking if you could take a moment of your time to fill out  
this survey. If you have several projects, it would be ideal to fill out  
the survey once for each project. However, if the answer to all the  
questions for every project is the same, you can fill out the survey once.  
¿What do I mean with TDD? En the lifecycle starts with unit-tests ->  
development -> green light -> refactor (this last step may be skipped in  
some cycles) ¿What do I mean with ATDD? It's like TDD, but the lifecycle  
starts with acceptance-tests, and inside the cycle there are many  
TDD-cycles. It may be a big simplification, and they are not mutually  
exclusive, but I'm interested to know if only unit-tests were used in the  
sense of UTDD (unit-TDD) or if acceptance tests guided the development. The  
thesis will be written in Spanish, since that's my native language, but  
I'll do my best effort to write the conclusions (in a paper or something)  
in English, so everyone that helped me can read it. Thank you very much!


Name and email It's not required to answer this question, the results will  
be completely anonymous and I won't give your personal information to  
anyone. I'm just asking to thank you later and ask any question that may  
arise from the survey.



Project Name and repository link * project name (or names if there are  
several) and link to the repository (SVN, CVS, GIT, etc). If the project  
has a bug tracker, please put the link too.



In which language was it developed? *



Which methodology was used to develop it? * I'll take into account only the  
core of the system, leaving out autogenerated code or UI. If you have any  
comment or clarification please put "other" and explain

TDD
ATDD
UTDD
BDD
NDD
STDD
Other:


xDD experience *

This was my first project with xDD
I have already done other projects with xDD


How much did you use xDD in the development of your project? *

Almost everything was done with it, 95 to 100% was developed with xDD
Very much, most of it was developed with xDD
Half of it, 50%
Little or nothing


If you have any additional comments you can use this space You can make  
here any clarification about the previous questions



Powered by Google Docs Report Abuse - Terms of Service - Additional Terms

[Junit-devel] Request for help: fix MethodSorter

[David S. <da...@sa...>]

Hi, JUnit users.

https://github.com/KentBeck/junit/issues/429 is a bug that needs a quick
fix in order to restore deterministic test ordering in JUnit 4.11.  Kevin
Cooney has been kind enough to even include the needed code in the comments
on the bug.  My day job is likely to keep me from checking in the quick fix
this week--if anyone's in the mood to do a good deed and open a pull
request, it would be a great help to all of us.  Thanks,

   David Saff

Re: [Junit-devel] Hamcrest Dependency

[Matthew F. <ma...@fa...>]

Hello,

Your patch for the update of the dependency will be very welcome.

BTW, the source code is on https://github.com/KentBeck/junit. If you
want to raise an issue or pull request, do it there, or contribute to
the existing issue https://github.com/KentBeck/junit/issues/36 (Sync
with most recent hamcrest?)

Matthew Farwell.

Le 13 mars 2012 15:38, Paul Hammant <pa...@ha...> a écrit :
> For the love of god, can you update your hamcrest dependency to 1.3.RC2
>
>      http://junit.cvs.sourceforge.net/viewvc/junit/junit/lib/
>
> - Paul
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] Hamcrest Dependency

[Paul H. <pa...@ha...>]

For the love of god, can you update your hamcrest dependency to 1.3.RC2

     http://junit.cvs.sourceforge.net/viewvc/junit/junit/lib/

- Paul

[Junit-devel] JUnit 4.10 is released

[David S. <da...@sa...>]

All,

JUnit 4.10 has been released.  It fixes a bug in packaging that
affected maven users who use up-to-date versions of hamcrest.  Thanks
to the efforts of a full cast of contributors, it also contains a
couple dozen new features and bugfixes.

The github model is working well as a way of maintaining JUnit as a
community.  If you've been waiting to jump in and fix that bug, now
may be the time.

As usual, you can download directly from
https://github.com/KentBeck/junit/downloads.  In addition, the jars
should already be up at Maven Central, assuming I've done it right
this time.

Release notes are at
https://github.com/KentBeck/junit/blob/4.10/doc/ReleaseNotes4.10.txt,
and copied below.

Thanks all, and keep it green,

   David Saff



## Summary of Changes in version 4.10 ##

Thanks to a full cast of contributors of bug fixes and new features.

A full summary of commits between 4.9 and 4.10 is on
[github](https://github.com/KentBeck/junit/compare/r4.9...4.10)

### junit-dep has correct contents ###

junit-dep-4.9.jar incorrectly contained hamcrest classes, which could
lead to version conflicts in projects that depend on hamcrest
directly.  This is fixed in 4.10 [@dsaff, closing gh-309]

### RuleChain ###

The RuleChain rule allows ordering of TestRules:

    public static class UseRuleChain {
    	@Rule
    	public TestRule chain= RuleChain
    	                       .outerRule(new LoggingRule("outer rule")
    	                       .around(new LoggingRule("middle rule")
    	                       .around(new LoggingRule("inner rule");

    	@Test
    	public void example() {
    		assertTrue(true);
    	}
    }

writes the log

    starting outer rule
    starting middle rule
    starting inner rule
    finished inner rule
    finished middle rule
    finished outer rule

### TemporaryFolder ###

- `TemporaryFolder#newFolder(String... folderNames)` creates
recursively deep temporary folders
  [@rodolfoliviero, closing gh-283]
- `TemporaryFolder#newFile()` creates a randomly named new file, and
`#newFolder()` creates a randomly named new folder
  [@Daniel Rothmaler, closing gh-299]

### Theories ###

The `Theories` runner does not anticipate theory parameters that have generic
types, as reported by github#64.  Fixing this won't happen until `Theories` is
moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
necessary machinery to the runner classes, and deprecates a method that only
the `Theories` runner uses, `FrameworkMethod`#producesType().
The Common Public License that JUnit is released under is now included
in the source repository.

Thanks to `@pholser` for identifying a potential resolution for github#64
and initiating work on it.

### Bug fixes ###

- Built-in Rules implementations
  - TemporaryFolder should not create files in the current working
directory if applying the rule fails
    [@orfjackal, fixing gh-278]
  - TestWatcher and TestWatchman should not call failed for
AssumptionViolatedExceptions
    [@stefanbirkner, fixing gh-296]
- Javadoc bugs
  - Assert documentation [@stefanbirkner, fixing gh-134]
  - ClassRule [@stefanbirkner, fixing gh-254]
  - Parameterized  [@stefanbirkner, fixing gh-89]
  - Parameterized, again [@orfjackal, fixing gh-285]
- Miscellaneous
  - Useless code in RunAfters [@stefanbirkner, fixing gh-289]
  - Parameterized test classes should be able to have `@Category` annotations
    [@dsaff, fixing gh-291]
  - Error count should be initialized in
junit.tests.framework.TestListenerTest [@stefanbirkner, fixing gh-225]
  - AssertionFailedError constructor shouldn't call super with null
message [@stefanbirkner, fixing gh-318]
  - Clearer error message for non-static inner test classes
[@stefanbirkner, fixing gh-42]

### Minor changes ###

- Description, Result and Failure are Serializable [@ephox-rob, closing gh-101]
- FailOnTimeout is reusable, allowing for retrying Rules
[@stefanbirkner, closing gh-265]
- New `ErrorCollector.checkThat` overload, that allows you to specify
a reason [@drothmaler, closing gh-300]

Re: [Junit-devel] Feature request: @Assumes

[David S. <da...@sa...>]

I'll respond at ju...@ya......

On Wed, Sep 14, 2011 at 5:18 AM, Stephen Connolly
<ste...@gm...> wrote:
> Consider the case where you are testing a List class...
>
> we have
>
> public class ListTest {
>
>  @Test
>  public void newListIsEmpty() {
>    assertThat(new List().isEmpty(), is(true);
>  }
>
>  @Test
>  public void newListHasSizeZero() {
>    assertThat(new List().size(), is(0));
>  }
>
>  @Test
>  public void addPutsAnElementIntoAnEmptyList() {
>    List l = new List();
>    l.add(new Object());
>    assertThat(l.isEmpty(), is(false));
>  }
>
>  @Test
>  public void addIncreasesSizeOfPopulatedListByOne() {
>    List l = new List();
>    l.add(new Object());
>    int s = l.size();
>    l.add(new Object());
>    assertThat(l.size(), is(s + 1));
>  }
>
> }
>
> We now want to add some tests of the delete functionality... but the
> reality is that until/unless some of the preceding tests are passing,
> the tests for delete are meaningless. We could have a perfectly
> functional List.delete() method but until such time as the above tests
> are passing, there is no way to tell that the method does not work.
>
> Now I could code my tests like such
>
>  @Test
>  public void deleteIsANoOpOnEmptyList() {
>    List l = new List();
>    assumeThat(l.isEmpty(), is(true));
>    l.delete(new Object());
>  }
>
> But all that I am doing is repeating code from the preceding tests,
> having changed all those tests' assertThat(...)s into assumeThat(...)s
>
> That does not seem agile to me, copy & paste & search & replace... ban
> code smell there
>
> I would much rather be able to annotate the tests with an @Assumes
> annotation that indicates that the test assumes that the specified
> tests are passing, e.g.
>
>  @Test
>  @Assumes("newListIsEmpty")
>  public void deleteIsANoOpOnEmptyList() {
>    List l = new List();
>    l.delete(new Object());
>  }
>
>  @Test
>  @Assumes({"newListIsEmpty","addPutsAnElementIntoAnEmptyList")
>  public void deleteRemovesAnElement() {
>    List l = new List();
>    Object o = new Object();
>    l.add(o);
>    l.delete(o);
>    assertThat(l.isEmpty(), is(true));
>  }
>
> In fact in my initial example of tests, there are some additional
> assumptions that I didn't make explicit
>
>
>  @Test
>  @Assumes("newListIsEmpty")
>  public void addPutsAnElementIntoAnEmptyList() {
>    ...
>  }
>
> and
>
>  @Test
>  @Assumes({"newListIsEmpty","addPutsAnElementIntoAnEmptyList")
>  public void addIncreasesSizeOfPopulatedListByOne() {
>    ...
>  }
>
> Now you could get some of this functionality via a TestRule...
>
> You could watch tests to see if they pass, and skip tests annotated
> with the annotation if assumed functionality is failing, but that
> would result in sporadic failures of, e.g. deleteRemovesAnElement
> because of the failing newListIsEmpty being executed _after_
> deleteRemovesAnElement rather than before.
>
> The simple point is that the test result of deleteRemovesAnElement is
> meaningless until its assumptions are true, and while I could code the
> assumptions with assumeThat(..)s C&P&S&R is even worse than C&P.
>
> Another alternative to @Assumes would be to invoke the assumed
> method(s) at the start of the test, e.g.
>
>  @Test
>  public void deleteRemovesAnElement() {
>    newListIsEmpty(); // verify assumed functionality
>    addPutsAnElementIntoAnEmptyList();  // verify assumed functionality
>    ...
>  }
>
> That gets rid of the C&P&S&R, but there are two issues with that:
>
>  1. We have to manually invoke any setup/tearDown methods, including
> all those of the rules that the test class has... very messy
>
>  2. The test fails when the assumed test fails. In actuality we can
> say nothing at all about whether deleteRemovesAnElement if a
> newListIsEmpty is not passing... yes we could code the test
> differently, but that is just moving our assumptions somewhere else.
>
> I am sure that there are others out there who feel there is a point 3...
>
>  3. We already ran those tests why waste time running them again?
>
> Well the answer to 3 is that these are UNIT tests which should be very
> fast, so what is the harm...
>
> So, in my view, best practice unit testing needs the ability to mark
> tests as assuming that other tests are passing, so that those tests
> can be skipped when the assumptions are known to be failing or
> skipped. [This is a deliberately loaded criteria... if the
> org.junit.runner.Request does not include the assumed test, then that
> test is neither known failing or known skipped, so we can run the test
> and output a warning that the failure may be because of assumed
> functionality... the use case of executing one and only one test
> repeatedly until you get that test passing]
>
> The annotation would have implications on test sorting, as any assumed
> tests would have to always happen before the assuming tests (as long
> as the assumed tests are in the org.junit.runner.Request)
>
> Also might have to be two annotations, e.g.
>
> @Assumes(methodNames)
> @AssumesClasses(classes)
>
> though in my view the @AssumesClasses is less critical, as these are
> UNIT tests and each test class should be independent to a large
> extent. However I am willing to consider that some people may have
> many test classes for one class under test, one test class containing
> all the tests of the constructors, another testing the Add methods,
> etc. in which case an @AssumesClasses annotation makes sense.
>
> Where tests contain a circular dependency, fail/error both tests
>
> Ok, let the critique begin!
>
> -Stephen
>
> P.S.
>
> I pinged Kent with an earlier version of this idea... but I think that
> he missed the point about eliminating C&P&S&R that this feature would
> provide because I didn't frame the idea correctly...
>
> ---------- Forwarded message ----------
> From: "Kent Beck"
> Date: 13 Sep 2011 17:11
> Subject: Re: JUnit and test dependencies
> To: "Stephen Connolly"
>
> Stephen,
>
> Thank you for articulating your idea so clearly. The short answer is that
> no, we don't plan to support dependencies. If I have tests that are slow
> enough that I care about dependencies, my most productive option is
> generally to work on the design of the software until the tests are fast
> enough that I no longer care. That said, my voice is only one of many. The
> longer answer is that I encourage you to post your idea on the JUnit mailing
> list for community discussion.
>
> Regards,
>
> Kent
>
> On Sep 13, 2011, at 8:32 AM, Stephen Connolly wrote:
>
>> Kent,
>>
>> Are there any plans for JUnit to support some test dependencies, such as:
>>
>> public class OnlyRunTestsThatMakeSenseTest {
>>
>>  @Test
>>  public void basicFunctionalityWorks() {
>>    ...
>>  }
>>
>>  @Test
>>  @AssumesPasses("basicFunctionalityWorks")
>>  public void advancedFunctionalityWorks() {
>>    ...
>>  }
>>
>>  @Test
>>  @AssumesPasses("basicFunctionalityWorks")
>>  public void basicFunctionalityWorksWithBevel() {
>>    ...
>>  }
>>
>>  @Test
>>
>  @AssumesPasses({"basicFunctionalityWorksWithBevel","advancedFunctionalityWorks"})
>>  public void advancedFunctionalityWorksWithBevel() {
>>    ...
>>  }
>>
>> }
>>
>> In the above example, no matter what sorting is applied,
>> basicFunctionalityWorks will always be run first, and the other three
>> tests will only be run if basicFunctionalityWorks passed.
>>
>> I see the above being completely in the spirit of unit testing, the
>> point with the above is that the @Before and @After's will be run
>> around each method, you are just saying that there is no point even
>> trying to test the advanced functionality when the basic functionality
>> is broken, skip those tests which we know cannot pass. That allows the
>> person writing advancedFunctionalityWorks to power through the setup
>> that depends on the basic functionality and not have to litter their
>> advanced test with asserts that are redundant because of the basic
>> functionality. Those people who are relying on side-effects should
>> really, for unit tests at least, be invoking the method who's
>> side-effects they depend on directly within their test method, rather
>> than relying on accidental ordering.
>>
>> Having said that, a second feature that I think would be good is
>> something like a @RunAfter and/or @RunBefore which would ensure that
>> the test method is run in sequence even if the before or after tests
>> fail/are skipped. with @RunAfter and @RunBefore I still think the
>> @Before and @After methods should be invoked in-between, this would be
>> moving towards more of a general purpose testing framework as opposed
>> to being unit-testing focused, but JUnit is just too good ;-)
>>
>> Thoughts?
>>
>> -Stephen
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry&reg; mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry&reg; DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] Feature request: @Assumes

[Stephen C. <ste...@gm...>]

Consider the case where you are testing a List class...

we have

public class ListTest {

  @Test
  public void newListIsEmpty() {
    assertThat(new List().isEmpty(), is(true);
  }

  @Test
  public void newListHasSizeZero() {
    assertThat(new List().size(), is(0));
  }

  @Test
  public void addPutsAnElementIntoAnEmptyList() {
    List l = new List();
    l.add(new Object());
    assertThat(l.isEmpty(), is(false));
  }

  @Test
  public void addIncreasesSizeOfPopulatedListByOne() {
    List l = new List();
    l.add(new Object());
    int s = l.size();
    l.add(new Object());
    assertThat(l.size(), is(s + 1));
  }

}

We now want to add some tests of the delete functionality... but the
reality is that until/unless some of the preceding tests are passing,
the tests for delete are meaningless. We could have a perfectly
functional List.delete() method but until such time as the above tests
are passing, there is no way to tell that the method does not work.

Now I could code my tests like such

  @Test
  public void deleteIsANoOpOnEmptyList() {
    List l = new List();
    assumeThat(l.isEmpty(), is(true));
    l.delete(new Object());
  }

But all that I am doing is repeating code from the preceding tests,
having changed all those tests' assertThat(...)s into assumeThat(...)s

That does not seem agile to me, copy & paste & search & replace... ban
code smell there

I would much rather be able to annotate the tests with an @Assumes
annotation that indicates that the test assumes that the specified
tests are passing, e.g.

  @Test
  @Assumes("newListIsEmpty")
  public void deleteIsANoOpOnEmptyList() {
    List l = new List();
    l.delete(new Object());
  }

  @Test
  @Assumes({"newListIsEmpty","addPutsAnElementIntoAnEmptyList")
  public void deleteRemovesAnElement() {
    List l = new List();
    Object o = new Object();
    l.add(o);
    l.delete(o);
    assertThat(l.isEmpty(), is(true));
  }

In fact in my initial example of tests, there are some additional
assumptions that I didn't make explicit


  @Test
  @Assumes("newListIsEmpty")
  public void addPutsAnElementIntoAnEmptyList() {
    ...
  }

and

  @Test
  @Assumes({"newListIsEmpty","addPutsAnElementIntoAnEmptyList")
  public void addIncreasesSizeOfPopulatedListByOne() {
    ...
  }

Now you could get some of this functionality via a TestRule...

You could watch tests to see if they pass, and skip tests annotated
with the annotation if assumed functionality is failing, but that
would result in sporadic failures of, e.g. deleteRemovesAnElement
because of the failing newListIsEmpty being executed _after_
deleteRemovesAnElement rather than before.

The simple point is that the test result of deleteRemovesAnElement is
meaningless until its assumptions are true, and while I could code the
assumptions with assumeThat(..)s C&P&S&R is even worse than C&P.

Another alternative to @Assumes would be to invoke the assumed
method(s) at the start of the test, e.g.

  @Test
  public void deleteRemovesAnElement() {
    newListIsEmpty(); // verify assumed functionality
    addPutsAnElementIntoAnEmptyList();  // verify assumed functionality
    ...
  }

That gets rid of the C&P&S&R, but there are two issues with that:

  1. We have to manually invoke any setup/tearDown methods, including
all those of the rules that the test class has... very messy

  2. The test fails when the assumed test fails. In actuality we can
say nothing at all about whether deleteRemovesAnElement if a
newListIsEmpty is not passing... yes we could code the test
differently, but that is just moving our assumptions somewhere else.

I am sure that there are others out there who feel there is a point 3...

  3. We already ran those tests why waste time running them again?

Well the answer to 3 is that these are UNIT tests which should be very
fast, so what is the harm...

So, in my view, best practice unit testing needs the ability to mark
tests as assuming that other tests are passing, so that those tests
can be skipped when the assumptions are known to be failing or
skipped. [This is a deliberately loaded criteria... if the
org.junit.runner.Request does not include the assumed test, then that
test is neither known failing or known skipped, so we can run the test
and output a warning that the failure may be because of assumed
functionality... the use case of executing one and only one test
repeatedly until you get that test passing]

The annotation would have implications on test sorting, as any assumed
tests would have to always happen before the assuming tests (as long
as the assumed tests are in the org.junit.runner.Request)

Also might have to be two annotations, e.g.

@Assumes(methodNames)
@AssumesClasses(classes)

though in my view the @AssumesClasses is less critical, as these are
UNIT tests and each test class should be independent to a large
extent. However I am willing to consider that some people may have
many test classes for one class under test, one test class containing
all the tests of the constructors, another testing the Add methods,
etc. in which case an @AssumesClasses annotation makes sense.

Where tests contain a circular dependency, fail/error both tests

Ok, let the critique begin!

-Stephen

P.S.

I pinged Kent with an earlier version of this idea... but I think that
he missed the point about eliminating C&P&S&R that this feature would
provide because I didn't frame the idea correctly...

---------- Forwarded message ----------
From: "Kent Beck"
Date: 13 Sep 2011 17:11
Subject: Re: JUnit and test dependencies
To: "Stephen Connolly"

Stephen,

Thank you for articulating your idea so clearly. The short answer is that
no, we don't plan to support dependencies. If I have tests that are slow
enough that I care about dependencies, my most productive option is
generally to work on the design of the software until the tests are fast
enough that I no longer care. That said, my voice is only one of many. The
longer answer is that I encourage you to post your idea on the JUnit mailing
list for community discussion.

Regards,

Kent

On Sep 13, 2011, at 8:32 AM, Stephen Connolly wrote:

> Kent,
>
> Are there any plans for JUnit to support some test dependencies, such as:
>
> public class OnlyRunTestsThatMakeSenseTest {
>
>  @Test
>  public void basicFunctionalityWorks() {
>    ...
>  }
>
>  @Test
>  @AssumesPasses("basicFunctionalityWorks")
>  public void advancedFunctionalityWorks() {
>    ...
>  }
>
>  @Test
>  @AssumesPasses("basicFunctionalityWorks")
>  public void basicFunctionalityWorksWithBevel() {
>    ...
>  }
>
>  @Test
>
 @AssumesPasses({"basicFunctionalityWorksWithBevel","advancedFunctionalityWorks"})
>  public void advancedFunctionalityWorksWithBevel() {
>    ...
>  }
>
> }
>
> In the above example, no matter what sorting is applied,
> basicFunctionalityWorks will always be run first, and the other three
> tests will only be run if basicFunctionalityWorks passed.
>
> I see the above being completely in the spirit of unit testing, the
> point with the above is that the @Before and @After's will be run
> around each method, you are just saying that there is no point even
> trying to test the advanced functionality when the basic functionality
> is broken, skip those tests which we know cannot pass. That allows the
> person writing advancedFunctionalityWorks to power through the setup
> that depends on the basic functionality and not have to litter their
> advanced test with asserts that are redundant because of the basic
> functionality. Those people who are relying on side-effects should
> really, for unit tests at least, be invoking the method who's
> side-effects they depend on directly within their test method, rather
> than relying on accidental ordering.
>
> Having said that, a second feature that I think would be good is
> something like a @RunAfter and/or @RunBefore which would ensure that
> the test method is run in sequence even if the before or after tests
> fail/are skipped. with @RunAfter and @RunBefore I still think the
> @Before and @After methods should be invoked in-between, this would be
> moving towards more of a general purpose testing framework as opposed
> to being unit-testing focused, but JUnit is just too good ;-)
>
> Thoughts?
>
> -Stephen

[Junit-devel] Issue 83: Support @Rule/@ClassRule annotation on methods as well as fields

[Matthew F. <ma...@fa...>]

Hello,

I came across this issue (https://github.com/KentBeck/junit/issues/83)
recently,
and I've created a fork & patch for it, but before I submit the pull
request, I wanted to check with the development list to see if I've done the
correct thing, and because this is the first contribution I've done for
junit.

The problem is this: Scala does not support the creation of public fields.
When you define a field with a public access modifier, this gets implemented
in the bytecode as a private field with public accessors. Therefore, it is
impossible to use @Rule annotations correctly. So, for instance, the
following code throws a initializationError ("Field thrown must be public"):

import org.junit._

class ClassTest {
  @Rule val thrown = ExpectedException.none()

  @Test
  def badInt: Unit = {
    thrown.expect(classOf[NumberFormatException])
    Integer.parseInt("one")
  }
}

even though everything looks correct from the point of view of the developer
(Scala fields and methods are public by default). One solution would be to
allow non-public fields to be used for @Rule annotations, but this was
rejected in (https://github.com/KentBeck/junit/issues/31). Another solution
to this problem is to allow the @Rule annotation to apply to methods as
well. So, in java, you'd have:

public class ExampleTest {
private ExpectedException thrown = ExpectedException.none();
 @Rule
public TestRule getThrown() {
return thrown;
}

@Test
public void badInt() {
            thrown.expect(NumberFormatException.class);
            Integer.parseInt("one");
}
}

and Scala:

class ClassTest {
  private val vthrown = ExpectedException.none()
  @Rule def thrown() = vthrown

  @Test
  def badInt: Unit = {
    vthrown.expect(classOf[NumberFormatException])
    Integer.parseInt("one")
  }
}

To keep things consistent, @ClassRule is also applicable to methods.

This is the change that I've made. It is available as a branch on my fork of
junit @ github:
https://github.com/matthewfarwell/junit/commit/c82458623b1dd5ed65d4f59e6f2b769f1338e13d

The main change is to BlockJUnit4ClassRunner#getTestRules() and
ParentRunner#classRules(). After creating the list of TestRule from the
@Rule annotated fields, it calls all of the @Rule annotated methods and adds
the TestRule objects returned to the list of TestRule. This means that if a
field and method are annotated with @Rule, then the field comes first, then
the method. However, if multiple fields are defined, then the order is still
undefined.

Validation for the @Rule annotated methods is as you would expect, the
methods must be public and return a TestType. In the case of @ClassRule, it
must also be static.

Could I please have some feedback on this: tell me if it fits in with the
current direction of junit development, and if it is an acceptable feature?

I am completely open to any suggestions or criticisms of my code.

Thanks.

Matthew Farwell.

[Junit-devel] Ongoing usefulness of acknowledgements.txt and bug fixes in release notes?

[David S. <da...@sa...>]

All,

To date, we've kept two pieces of documentary metadata along with
JUnit: acknowledgements.txt and ReleaseNotes files.  In order:

1) acknowledgements.txt is an attempt at a log of everyone outside of
the primary maintainers who has contributed in some way to JUnit.  It
was, I believe, originally intended to serve two purposes: (a) for
traceability, should any legal questions arise about the provenance of
a piece of code, (b) before github, we often ended up massaging (or
replacing) patches ourselves before committing them to CVS, and we
wanted a way to genuinely thank and remember the original authors.

GitHub now helps with both of these issues: since we can discuss pull
requests before they're accepted, we can ask contributors to fix minor
issues, and github keeps excellent track of what came from where.  In
addition, distributed maintenance of the acknowledgements.txt file has
become a pain, since as a linear document, there is often a race
condition between appended items.

2) I've been asking committers to include updates to ReleaseNotes
files as part of check-ins.  This has some of the same issues as
above: it's no longer strictly necessary given GitHub support, and
also leads to race conditions.

So, my proposal is:

1) Drop further appends to acknowedgements.txt
2) Adopt a more formal approach to git commit messages, following
along http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html,
along release notes to be largely auto-generated at release time.

Thoughts?

Re: [Junit-devel] Help ! I need example of junit test with hibernate && spring

[David S. <da...@sa...>]

Googling for "JUnit hibernate" reveals some pretty good resources.

   David Saff

On Wed, Aug 31, 2011 at 11:13 PM, Meriem ELBOUZIDI
<elb...@gm...> wrote:
> hello
>
>      I want to test my classes DAO and services using junit . I seek for
> tutorial or simple example
>
> --
>
> EL  BOUZIDI  Meriem
> computer science engineering student (3th academic year)
> National School of computer science and systems analysis (ENSIAS)
> Mohammed 5th-Souissi University,
> Rabat, Morocco.
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

[Junit-devel] Help ! I need example of junit test with hibernate && spring

[Meriem E. <elb...@gm...>]

hello


     I want to test my classes DAO and services using junit . I seek for
tutorial or simple example

-- 


EL  BOUZIDI  Meriem
computer science engineering student (3th academic year)
National School of computer science and systems analysis (ENSIAS)
Mohammed 5th-Souissi University,
Rabat, Morocco.

Re: [Junit-devel] [junit] JUnit 4.9 released!

[David S. <da...@sa...>]

So, one minute--does this mean that the beta staging repositories that
I closed, but didn't release, were not available to users for beta
testing?

   David Saff

On Wed, Aug 24, 2011 at 11:40 AM, Max Bowsher <ma...@f2...> wrote:
> Yes, that looks fine.
>
> You probably also want to either promote or drop - probably drop - the
> remaining active staging repositories containing 4.9 beta releases from
> oss.sonatype.org.
>
> Max.
>
> On 24/08/11 12:35, David Saff wrote:
>> I just had to click the button, it turns out.  It should now be
>> promoted.  Please let me know if it looks that way to you (since I'm
>> still, obviously, new at this).
>>
>>    David Saff
>>
>> On Wed, Aug 24, 2011 at 7:29 AM, Max Bowsher <ma...@f2...> wrote:
>>> On 23/08/11 16:44, David Saff wrote:
>>>> Hello, everyone.  We're happy to announce the release of JUnit 4.9.
>>>
>>> Great!
>>>
>>> I see you've already staged it at oss.sonatype.org - what still needs to
>>> happen before that staging repository gets promoted into Maven Central?
>>>
>>> Max.
>>>
>>>
>
>
>

Re: [Junit-devel] [junit] JUnit 4.9 released!

[David S. <da...@sa...>]

I just had to click the button, it turns out.  It should now be
promoted.  Please let me know if it looks that way to you (since I'm
still, obviously, new at this).

   David Saff

On Wed, Aug 24, 2011 at 7:29 AM, Max Bowsher <ma...@f2...> wrote:
> On 23/08/11 16:44, David Saff wrote:
>> Hello, everyone.  We're happy to announce the release of JUnit 4.9.
>
> Great!
>
> I see you've already staged it at oss.sonatype.org - what still needs to
> happen before that staging repository gets promoted into Maven Central?
>
> Max.
>
>