Hi
Take a look at
http://www-128.ibm.com/developerworks/library/j-ant/

and

http://dsd.lbl.gov/~ksb/Scratch/jajucc_hw.html


These URLs start from the "Hello World" and tell you how to write an
Ant Build.xml to include the JUnit test cases also.

Could be a good point to start your learning process.

Regards
Kaushal

--- In junit@yahoogroups.com, "greg_plummer" <Greg.plummer@...> wrote:
>
> --- In junit@yahoogroups.com, "kultstatus77" <onlineguy@> wrote:
> >
> > Hi,
> >
> > I'm looking for information on running JUnit tests during an
> automated
> > build process. I do
> >
> > know that it's possible to include JUnit tasks in Ant's build.xml,
> but
> > I'm looking for a way
> >
> > to make JUnit tests mandatory for every piece of code that's written
> > and commited to our
> >
> > CVS. Is there a way to control uploads to CVS regarding JUnit?
> >
> > Another info I'd like to have: is there a way to decide dynamically
> > which tests Ant has to
> >
> > run (like running tests only for changed parts of source code, for
> > example)? I do know that
> >
> > it is common to run all the tests all the time, I'd just like to get
> > to know all the
> >
> > possibilities Ant offers when it comes to JUnit.
> >
>
> You could use the CruiseControl tool for automating your build
> process. You can tell it to run the build every time that something
> is checked into CVS. I would recommend buying the book "Pragmatic
> Project Automation" by Mike Clark. It describes how to automate your
> build process, including how to use CruiseControl and how to run to
> build when things are checked in to CVS.
>

Greetings David,

Thanks for the email! I understand where you're coming from.

> I find that I end up with very few tests that actually want to say
>    assertTrue( 2 < n && n < 10, "n should be inside the (2, 10) interval");

Agreed.

> > So, I don't usually bother with assertion failure messages.
>
> Out of true curiosity, to what extent is this because you're already
> using the built-in assertion failure sugar in assertEquals?

Correct, I'm usually employing assertEquals. I'd say out of the small
percentage of assertions where I'm *not* using assertEquals, I feel
compelled to annotate less than one out of five of those. Same reason:
it's more effort than I feel compelled to do at the time, so I wait
until I need to add it (i.e. when a test breaks post-development).

If what you're suggesting is that most of my assertions will be as
simple and readable as:
    assertThat(x, eq(5));
you're right. It's the 80-20 rule, and I guess my take is that I'm
happy enough to write custom assert methods for my 20% rather than to
try and build/use a framework that deals with every possibility. (The
other thought would be to punt, not using the framework when things
got too ugly, but that sort of inconsistent solutions seems to make
things even harder to follow.)

I experimented with one of the frameworks a good while ago. Still, I'd
be happy to give a more recent version a try. Can you re-post a link
to one you recommend?

Many thanks,
Jeff

----
David Saff said...

Thanks for a thoughtful message.  I'll try to be fair to your
points--this is not something that I feel is immensely important to
get agreement on, but I'm hoping to help those who haven't tried
assertThat to get a feeling for it's power, perhaps just enough of a
glimpse that they'll try it, and see how it goes.  (Any apostate
assertThat users out there?  Tried it, hated it, gone back?)

...

Hi
     If you are trying to automate explorer based test cases using JUnit there's
an excellent library called watij. You can use this tool in JUnit enviroment for
hosting web application as well as form filling and many other jobs you think
for a browser based test case. Currently this tool supports only IE but most
probably in future it will be supporting Fire Fox. You can maintain ant driven
JUnit test cases. Heres the URL you find details about it. http://www.watij.com/

You can make simple call in test cases like ie.call() etc.

Thanks
Avinash


----- Original Message ----
From: David Saff <saff@...>
To: junit@yahoogroups.com
Sent: Thursday, 30 November, 2006 9:23:27 PM
Subject: Re: [junit] re:using weblogic with junit

On 11/29/06, Dhanapalan <c.dhanapalan@ gmail.com> wrote:
> Hi All,
> I'm newer to Junit. I would like automate one web page testing where I'm
> giving manual feed. How to automate using Junit. please provide some idea
> regarding this.

Dhanapalan,

Can you give more details what you mean by "manual feed"? Thanks,

David Saff







___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of
use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

[Non-text portions of this message have been removed]

Hi David,

> On 11/30/06, Jeff Langr <jeff@...> wrote:
> > The main benefit of literate programming that I gather from reading
> > earlier messages is that it makes the error messages easier to read.
> > Given this example:
> >     assert(that(n).greaterThan(2).and().that(n).lessThan(10))
>
> First, I don't believe that there's a framework currently in
> existence that looks like that (am I wrong?)  Second, as I've
> said elsewhere, I think this is not a useful example.  I find
> that I end up with very few tests that actually want to say

I actually had this for a while in my own C# framework. Even without
the parentheses, I didn't find the And syntax that readable. It's
not the sort of thing people expect in a curly-brace language.

> assertTrue( 2 < n && n < 10, "n should be inside the (2, 10)
> interval");
>
> whether I'm using assertThat or not.  Do you?

It's always occasional for me and, with one exception, it's easy to
substitute two asserts for it anyway. The exception is when I want
to make multiple tests over every item in a collection. In that case,
I either use & - which I do support - or simply build up the constraint
in lines of code. It's not as readable as separate asserts, but it allows
me to pass over the collection only once without writing an explicit loop.

Some people would probably prefer the loop - not a problem. :-)

<snip/>

> 2) Just as I find that the pressure to make my classes
> testable results in designs that appeal to me, regardless of
> testability, I find that assertThat pressures me to create
> designs that have easily asserted-on values.  For example,
> where before I might have written:
>
> assertTrue(process.finished() && process.returnValue() == 0),
>
> I'm more likely to write (partially _because_ of the
> clunkiness of the constraint syntax):
>
> assertThat(process.status(), eq(Process.SUCCESSFUL_RETURN));
>
> Now, I've found a new class, ProcessStatus, that proves
> useful in rendering progress bars and info logs.

Now this gets to a quality of test framework apis that I find
more important than readability: we could clal it writability
I guess, or expressibility. :-)

If it's easy to express things naturally, you will tend to
create and interfaces that are natural to use. I can't prove
that, but having experimented with this paradigm, I know
it has been true for me.

Charlie

Hi Joe,

> You've heard my French. Would you buy that book?

I think it would have a certain historical value. :-)

Charlie

Cédric Beust ♔ schrieb:
> On 11/28/06, Michael Feathers <mfeathers@...> wrote:
>> I think that JUnit3 test code is more beautiful than its competitors and
>> successors because it's appropriately minimal. It makes good things easy
>> and bad things difficult.
>
>
> Seriously?
>
> You find this:
>
>   public void testDivideByZero() {
>     try {
>       int n = 2 / 0;
>       fail();
>     }
>     catch(ArithmeticException ex) {
>       // pass
>     }
> }
>
>
> easier to read than this:
>
>   @Test(expected=ArithmeticException.class)
>   public void divideByZero() {
>     int n = 2 / 0;
>   }

Although I am using JUnit 4 now, I haven't yet used the
expected-parameter - I don't test for exceptions particularly often.

Having said that, to me

     public void testDivideByZero() {
       try {
         int n = 2 / 0;
         fail();
       }
       catch(ArithmeticException expected) {
       }
     }

actually reads better than the annotation, yes. It's a pattern I can
spot and parse easily. (Ignoring for the moment that the test name is
horrible.) I have to do more involved parsing to understand the JUnit 4
example.

Might just be me getting old, though.

Cheers, Ilja

On 11/30/06, J. B. Rainsberger <jbrains762@...> wrote:
>
>
> You've heard my French. Would you buy that book?


I can help with that :-)

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

Hopefully someone can explain this situation:

Public class sgTest extend TestCase {
    File myFile;

    protected void setUp() throws Exception {
       super.setUp();
    }

    public void testMethodA() throws Exception {
       myFile = "somefile.csv";
       ...
    }

    public void testMethodB() throws Exception {
       System.out.println{"myFile = " + myFile};
       ...
    }
}

The output is: myFile = null

I ran into a problem that I believe is a side effect of JUnit using
reflection. If I declare a class variable which is later define in one
test method then used in an another test method the variable's value
seems to have been re-initialized (overwritten as null). To get around
this in the class declaration I added the 'static' construct:

static File myFile;

Any ideas?

Scott

JUnit reinstantiates the test class before each test method.  Move the
assignment to setUp().

--
Cedric
http://testng.org


On 12/1/06, rsg00usa <sglaser@...> wrote:
>
> Hopefully someone can explain this situation:
>
> Public class sgTest extend TestCase {
>    File myFile;
>
>    protected void setUp() throws Exception {
>       super.setUp();
>    }
>
>    public void testMethodA() throws Exception {
>       myFile = "somefile.csv";
>       ...
>    }
>
>    public void testMethodB() throws Exception {
>       System.out.println{"myFile = " + myFile};
>       ...
>    }
> }
>
> The output is: myFile = null
>
> I ran into a problem that I believe is a side effect of JUnit using
> reflection. If I declare a class variable which is later define in one
> test method then used in an another test method the variable's value
> seems to have been re-initialized (overwritten as null). To get around
> this in the class declaration I added the 'static' construct:
>
> static File myFile;
>
> Any ideas?
>
> Scott
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
Cédric


[Non-text portions of this message have been removed]

On 12/1/06, Jeff Langr <jeff@...> wrote:
> I experimented with one of the frameworks a good while ago. Still, I'd
> be happy to give a more recent version a try. Can you re-post a link
> to one you recommend?

All of my experience with any of the public tools has been with JMock.
  JMock 1, available from

http://jmock.org

has both the mocking library and the constraint library, with
assertThat.  In the next generation, the constraint library has been
renamed to hamcrest, which is being developed independently:

http://sourceforge.net/projects/hamcrest

A warning: hamcrest uses (but doesn't, I believe, require) generic
types.  I was one of several users pushing for this, but now that it's
here, I have mixed feelings about it.  I tend to believe the main
issue isn't the generics themselves, but unnecessarily poor type
inference from current compilers.  This is an orthogonal issue, with
the same kinds of benefits and drawbacks that would come from
declaring assertEquals as

public <T> void assertEquals(T expected, T actual).

Have fun,

    David Saff

RMock (rmock.sf.net) also has an assertThat library.
It is like JMock 1.x but using EasyMock 2 style syntax
and not requiring Java 5. It has a few quirks and
isn't as popular as JMock but has some interesting
features that you might find useful. It seems to have
slowed (in terms of active development) in recent times.

Cheers, Paul.

David Saff wrote:
>
>
> On 12/1/06, Jeff Langr <jeff@...
> <mailto:jeff%40langrsoft.com>> wrote:
>  > I experimented with one of the frameworks a good while ago. Still, I'd
>  > be happy to give a more recent version a try. Can you re-post a link
>  > to one you recommend?
>
> All of my experience with any of the public tools has been with JMock.
> JMock 1, available from
>
> http://jmock.org <http://jmock.org>
>
> has both the mocking library and the constraint library, with
> assertThat. In the next generation, the constraint library has been
> renamed to hamcrest, which is being developed independently:
>
> http://sourceforge.net/projects/hamcrest
> <http://sourceforge.net/projects/hamcrest>
>
> A warning: hamcrest uses (but doesn't, I believe, require) generic
> types. I was one of several users pushing for this, but now that it's
> here, I have mixed feelings about it. I tend to believe the main
> issue isn't the generics themselves, but unnecessarily poor type
> inference from current compilers. This is an orthogonal issue, with
> the same kinds of benefits and drawbacks that would come from
> declaring assertEquals as
>
> public <T> void assertEquals(T expected, T actual).
>
> Have fun,
>
> David Saff
>
>

My two cents:  JMock is falling behind and EasyMock has the lead today.   It
has more features, makes very clever use of generics and has much better
static typing than JMock (where you still specify methods with Strings).

I would suggest trying both thoroughly before making a choice.

--
Cedric
http://testng.org


On 12/2/06, David Saff <saff@...> wrote:
>
> On 12/1/06, Jeff Langr <jeff@...> wrote:
> > I experimented with one of the frameworks a good while ago. Still, I'd
> > be happy to give a more recent version a try. Can you re-post a link
> > to one you recommend?
>
> All of my experience with any of the public tools has been with JMock.
> JMock 1, available from
>
> http://jmock.org
>
> has both the mocking library and the constraint library, with
> assertThat.  In the next generation, the constraint library has been
> renamed to hamcrest, which is being developed independently:
>
> http://sourceforge.net/projects/hamcrest
>
> A warning: hamcrest uses (but doesn't, I believe, require) generic
> types.  I was one of several users pushing for this, but now that it's
> here, I have mixed feelings about it.  I tend to believe the main
> issue isn't the generics themselves, but unnecessarily poor type
> inference from current compilers.  This is an orthogonal issue, with
> the same kinds of benefits and drawbacks that would come from
> declaring assertEquals as
>
> public <T> void assertEquals(T expected, T actual).
>
> Have fun,
>
>    David Saff
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
Cédric


[Non-text portions of this message have been removed]

The front page of junit.org still links to junit-4.1.zip

Martijn

On 11/16/06, David Saff <saff@...> wrote:
> All,
>
>  We've released JUnit 4.2. This is primarily a bug-fix release, and is up on
>  SourceForge now. Release notes are at:
>
> http://sourceforge.net/project/shownotes.php?group_id=15278&release_id=464208
>

--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>

I am trying to create JUnit report using ant's JUnit task.

The classes to be tested use a static cache oject to load and store
the config files. If in container, the config files should load only
once. But when using ant's JUnit task, the config files are loaded for
each test classes. How to config the ant script to make the test
classes to share the same classloader?

I tried to put all the testcases in a testsuite. The config files are
loaded only once. but in the report, it won't list all the test cases.
It only shows one testsuite.

Thanks

I can think of a few options:

1. set forkmode to "once" or "batch" in the junit-task (haven't tried this
one)
2. create a testsuite with all your tests (for example via rMocks
dynamicTestSuite or jUnit addOns equivalent) (if you're using jUnit4 there
is now a custom runner for this, I forgot the name of it but if you search
the archive for "runner" you should find a recent message.

I hope this gives you some ideas.
/Joakim Ohlrogge

On 12/4/06, jiaoyangs <jiaoyangs@...> wrote:
>
>   I am trying to create JUnit report using ant's JUnit task.
>
> The classes to be tested use a static cache oject to load and store
> the config files. If in container, the config files should load only
> once. But when using ant's JUnit task, the config files are loaded for
> each test classes. How to config the ant script to make the test
> classes to share the same classloader?
>
> I tried to put all the testcases in a testsuite. The config files are
> loaded only once. but in the report, it won't list all the test cases.
> It only shows one testsuite.
>
> Thanks
>
>
>


[Non-text portions of this message have been removed]

David Saff wrote:

>On 11/29/06, Michael Feathers <mfeathers@...> wrote:
>
>
>>Steve Freeman has mentioned that the test
>>prefix naming convention isn't really necessary in JUnit. You can just
>>use reflection to pick up all of the methods on a test case class that
>>accept and return void and treat them as tests.
>>
>>
>
>True, that.  I've invited Steve to contribute a custom runner for
>JUnit 4 that does just that.  There's two specific problems with the
>suggestion:
>
>1) JUnit 4 allows test cases to inherit from domain classes, sometimes
>a useful trick when migrating legacy code, which would break using
>this scheme.
>2) We would then need to annotate classes, or packages, or something,
>to indicate which classes should be used as tests, to allow nifty test
>runners like ant or Eclipse to work their automagic.
>
>Neither of these is a death knell to the idea.  But I'm still afraid
>of introducing "punning" like this by default.  As an example, Ruby's
>test::unit, by default, automatically picks up any loaded subclass of
>TestCase (wouldn't _that_ be lovely) and runs it.  But doing so makes
>the Abstract Test Case pattern unusable.
>
>So far, this is mostly justification of conservatism, so I'm open to
>further opinionating.
>
>
It's a funny thing about this.  I guess that this could work for JUnit
but sometimes ideas just need a different context to shine.. .the idea
could be great with one set of feature but then be odd when laid along
side another set of features.


Michael Feathers
michaelfeathers.typepad.com
www.objectmentor.com

File myfile = "stringliteral";

That won't compile, surely? Once that's sorted, Cédric has pointed you in
the right direction.

James

On 02/12/06, Cédric Beust ♔ <cbeust@...> wrote:
>
>   JUnit reinstantiates the test class before each test method. Move the
> assignment to setUp().
>
> --
> Cedric
> http://testng.org
>
> On 12/1/06, rsg00usa <sglaser@... <sglaser%40yahoo-inc.com>>
> wrote:
> >
> > Hopefully someone can explain this situation:
> >
> > Public class sgTest extend TestCase {
> > File myFile;
> >
> > protected void setUp() throws Exception {
> > super.setUp();
> > }
> >
> > public void testMethodA() throws Exception {
> > myFile = "somefile.csv";
> > ...
> > }
> >
> > public void testMethodB() throws Exception {
> > System.out.println{"myFile = " + myFile};
> > ...
> > }
> > }
> >
> > The output is: myFile = null
> >
> > I ran into a problem that I believe is a side effect of JUnit using
> > reflection. If I declare a class variable which is later define in one
> > test method then used in an another test method the variable's value
> > seems to have been re-initialized (overwritten as null). To get around
> > this in the class declaration I added the 'static' construct:
> >
> > static File myFile;
> >
> > Any ideas?
> >
> > Scott
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> --
> Cédric
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

How can I create a unit test for this specific method, Here is the
part of the code in the method:


for(int i =0; i< count; i++)
{
	 Selling = (com.company.Selling) SellingArray[i]);
	 if(!((Selling.getStatus().equals("SS"))||(Selling.getStatus
().equals("HS"))||(Selling.getStatus().equals("HK"))))
	 {
		 segmentFailure.put(new Integer(i), null);
	 }
}

I want to have a unit test for the conditional statement here without
using the canned output came from the class Selling.

What whould you like to test? Which condition should always be false
or always be true? Should something be not null?

--- In junit@yahoogroups.com, "avg_3000" <avg_3000@...> wrote:
>
> How can I create a unit test for this specific method, Here is the
> part of the code in the method:
>
>
> for(int i =0; i< count; i++)
> {
>  Selling = (com.company.Selling) SellingArray[i]);
>  if(!((Selling.getStatus().equals("SS"))||(Selling.getStatus
> ().equals("HS"))||(Selling.getStatus().equals("HK"))))
>  {
> 	 segmentFailure.put(new Integer(i), null);
>  }
> }
>
> I want to have a unit test for the conditional statement here without
> using the canned output came from the class Selling.
>

I would start by extracting a method for the conditional you're
concerned about, so that the code becomes:

for(int i =0; i< count; i++)
{
        Selling = (com.company.Selling) SellingArray[i]);
        if(! isValid(Selling))
        {
                segmentFailure.put(new Integer(i), null);
        }
}

I'm guessing at the method name.  Once that exists, unit testing is
easy.  Good luck,

    David Saff

On 12/5/06, avg_3000 <avg_3000@...> wrote:
> How can I create a unit test for this specific method, Here is the
> part of the code in the method:
>
>
> for(int i =0; i< count; i++)
> {
>         Selling = (com.company.Selling) SellingArray[i]);
>         if(!((Selling.getStatus().equals("SS"))||(Selling.getStatus
> ().equals("HS"))||(Selling.getStatus().equals("HK"))))
>         {
>                 segmentFailure.put(new Integer(i), null);
>         }
> }
>
> I want to have a unit test for the conditional statement here without
> using the canned output came from the class Selling.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

I've read all over the place that it's a bad idea to include multiple
assertions in one test case, but it seems to me that sometimes it's
very useful. For example, I have a fairly straightforward DAO and I
want to test the create method.  But to really test it, I need to
retrieve it afterwards and make sure it was successfully created.  And
I need to clean it up afterwards (or the test will fail next time I
run it and try to create a duplicate), so I call my delete method.
There I've exercised 3 methods of my DAO, not just one.  So it feels
like it would save time to assert that each step of the process
succeeded.

Example:
   public void testEmployeeCRUD()
   throws Exception
   {
	 int sizeBeforeAdding = em.listEmployees().size();
	 _employeeId = em.createEmployee(_fname, _lname, _jobtitle);

         int sizeAfterAdding = em.listEmployees().size();
         log.debug("Created employee " + _employeeId);
         //Make sure that the new list is longer than the old list
	 assertTrue("Create employee failed", sizeAfterAdding>sizeBeforeAdding);

         Employee emp = em.getEmployee(_employeeId);
         assertEquals("getEmployee failed", emp.getLName(), _lname);
         log.debug("Retrieved employee " + emp.getLName());

         em.deleteEmployee(emp);

         int sizeAfterDelete = em.listEmployees().size();

         //Make sure that the length of the list after delete
         //is the same as it was before we added
         assertEquals("Delete employee failed", sizeAfterDelete,
sizeBeforeAdding);
         log.debug("Deleted employee");
     }

The preceding code works just fine.  If the test fails, I'd look in
the failure message to see which part of it failed, and it seems like
that's not too difficult.  I know it's not following best practices
because it calls 4 separate methods, but when I tried writing a test
for each of those methods, I ended up either calling the other ones in
the setup/teardown or by essentially recreating them in a sample data
loading operation.  I'm trying to do good TDD and to convince a
colleague who resists unit tests at all, so I don't want to do things
"wrong" but I also don't want to make life tremendously more difficult
without understanding the real reason behind the recommendations.

Does anyone have any thoughts on this principle?  I appreciate the
intelligent exchanges I've seen on the list in the past so I hope to
get a thoughtful discussion going.

Thanks very much!
Julie

Hey Guys,

I'm testing a method.

When I have the method by itself it tests fine.

When I put another test in front of it like this:
	 public void testCreateResourceSet()
	 {
		 //Stub
		 assertTrue(true);
	 }

I get an exception like this:
java.lang.ExceptionInInitializerError
	 at
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83\
)
	 at
org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)

....

I also get the same exception when testing with Maven,
so I know it is localized to JUnit.

Has anyone else seen behavior like this?

I'll paste the full test case below, in case anyone
wants to look at it further.

Cheers,
- Ole


package org.jpackage.test;

import java.io.File;
import java.io.IOException;

import org.apache.maven.artifact.Artifact;
import
org.apache.maven.artifact.factory.ArtifactFactory;
import
org.apache.maven.artifact.repository.ArtifactRepository;
import
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
import
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
import org.apache.maven.plugin.MojoExecutionException;
import
org.apache.maven.plugin.testing.AbstractMojoTestCase;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.jpackage.impl.JPackageMojoHelperBufferImpl;
import org.jpackage.impl.JPackageMojoImpl;
import org.jpackage.JPackageMojoConstants;
import org.jpackage.impl.JPackageMojoHelperImpl;

import
com.pyramidetechnologies.emf.utils.EMFUtilities;

public class JPackageMojoHelperTest extends
AbstractMojoTestCase implements JPackageMojoConstants
{

	 private JPackageMojoImpl mojo = null;
	 private ArtifactRepository artifactRepository = null;
	 private ResourceSet resourceSet = null;

	 protected void setUp() throws Exception {

		 // required for mojo lookups to work
		 super.setUp();

		 File pluginXml = new File(getBasedir(),
				 "src/test/resources/plugin-config.xml");
		 mojo = (JPackageMojoImpl) lookupMojo(
				 "xml2spec.mojo",
				 "org.jpackage",
				 "1.0-SNAPSHOT",
				 "generate",
				 pluginXml,
				 false);

		 resourceSet =
JPackageMojoHelperImpl.createResourceSet();
	 }

	 public void testCreateResourceSet()
	 {
		 //Stub
		 assertTrue(true);
	 }

	 public void testLoadPomResource() throws
MojoExecutionException
	 {
		 String artifactId = "apacheds-server-main";
		 String groupId = "org.apache.directory.server";
		 String version = "1.5.0-SNAPSHOT";

		 ArtifactFactory artifactFactory =
mojo.getArtifactFactory();
		 assertNotNull(artifactFactory);

		 Artifact pomArtifact =
artifactFactory.createArtifact(groupId, artifactId,
				 version, null, "pom");
		 assertNotNull(pomArtifact);

		 String path = pathOf(pomArtifact);
		 File file = new File(path);
		 assertTrue(file.exists());

		 pomArtifact.setFile(file);

		 Resource resource = null;
		 resource =
JPackageMojoHelperImpl.loadPomResource(pomArtifact,
resourceSet);

		 assertNotNull(resource);
	 }

	 private static String pathOf(Artifact artifact)
	 {
		 ArtifactRepositoryLayout artifactRepositoryLayout =
new DefaultRepositoryLayout();
		 String artifactPath =
artifactRepositoryLayout.pathOf(artifact);
		 return REPOSITORY_BASE_DIRECTORY + artifactPath;
	 }

	 private static String REPOSITORY_BASE_DIRECTORY =
"/home/ole/.m2/repository/";

}



________________________________________________________________________________\
____
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

I've been using multiple assert methods in my test cases for the past
couple years and haven't died from it yet.


Todd.


> -----Original Message-----
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On
> Behalf Of shefehs
> Sent: Wednesday, December 06, 2006 1:52 PM
> To: junit@yahoogroups.com
> Subject: [junit] Philosophical question--Multiple assertions
> in one test case
>
> I've read all over the place that it's a bad idea to include
> multiple assertions in one test case, but it seems to me that
> sometimes it's very useful. For example, I have a fairly
> straightforward DAO and I want to test the create method.
> But to really test it, I need to retrieve it afterwards and
> make sure it was successfully created.  And I need to clean
> it up afterwards (or the test will fail next time I run it
> and try to create a duplicate), so I call my delete method.
> There I've exercised 3 methods of my DAO, not just one.  So
> it feels like it would save time to assert that each step of
> the process succeeded.
>
> Example:
>   public void testEmployeeCRUD()
>   throws Exception
>   {
>  int sizeBeforeAdding = em.listEmployees().size();
>  _employeeId = em.createEmployee(_fname, _lname, _jobtitle);
>
>         int sizeAfterAdding = em.listEmployees().size();
>         log.debug("Created employee " + _employeeId);
>         //Make sure that the new list is longer than the old list
>  assertTrue("Create employee failed",
> sizeAfterAdding>sizeBeforeAdding);
>
>         Employee emp = em.getEmployee(_employeeId);
>         assertEquals("getEmployee failed", emp.getLName(), _lname);
>         log.debug("Retrieved employee " + emp.getLName());
>
>         em.deleteEmployee(emp);
>
>         int sizeAfterDelete = em.listEmployees().size();
>
>         //Make sure that the length of the list after delete
>         //is the same as it was before we added
>         assertEquals("Delete employee failed",
> sizeAfterDelete, sizeBeforeAdding);
>         log.debug("Deleted employee");
>     }
>
> The preceding code works just fine.  If the test fails, I'd
> look in the failure message to see which part of it failed,
> and it seems like that's not too difficult.  I know it's not
> following best practices because it calls 4 separate methods,
> but when I tried writing a test for each of those methods, I
> ended up either calling the other ones in the setup/teardown
> or by essentially recreating them in a sample data loading
> operation.  I'm trying to do good TDD and to convince a
> colleague who resists unit tests at all, so I don't want to
> do things "wrong" but I also don't want to make life
> tremendously more difficult without understanding the real
> reason behind the recommendations.
>
> Does anyone have any thoughts on this principle?  I
> appreciate the intelligent exchanges I've seen on the list in
> the past so I hope to get a thoughtful discussion going.
>
> Thanks very much!
> Julie
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Cédric Beust ♔ wrote:

> My two cents: JMock is falling behind and EasyMock has the lead today. It
> has more features, makes very clever use of generics and has much better
> static typing than JMock (where you still specify methods with Strings).
>
> I would suggest trying both thoroughly before making a choice.

I would suggest that, too. Cedric's statement seems to assume that both
generics and static typing are a good thing. I dislike generics (I type
more to get a little more protection) and I don't find static typing
valuable.

I can't counteract Cedric's claim that EasyMock has more features, apart
from those that don't matter to me, because I haven't used EasyMock
since 2004.

Take care.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

J. B. Rainsberger writes:

> Cédric Beust ♔ wrote:
>
>> My two cents: JMock is falling behind and EasyMock has the lead today. It
>> has more features, makes very clever use of generics and has much better
>> static typing than JMock (where you still specify methods with Strings).
>>
>> I would suggest trying both thoroughly before making a choice.
>
> I would suggest that, too. Cedric's statement seems to assume that both
> generics and static typing are a good thing. I dislike generics (I type
> more to get a little more protection) and I don't find static typing

Jmock 2.0 (still in cvs only) incorporates static typing (hence refactor
safe) with the jmock style.

Nat, Steve, (if you are listening) if you make a beta release I would
certainly try it out at work and I suspect others would as well.

  - Neil

You could refactor the long if into a new method and then test that.

for ...
  {
     if (Selling.isStatusBlah())...
  }

and then you'd have a test method for isStatusBlah in your test suite.

--- In junit@yahoogroups.com, "avg_3000" <avg_3000@...> wrote:
>
> How can I create a unit test for this specific method, Here is the
> part of the code in the method:
>
>
> for(int i =0; i< count; i++)
> {
>  Selling = (com.company.Selling) SellingArray[i]);
>  if(!((Selling.getStatus().equals("SS"))||(Selling.getStatus
> ().equals("HS"))||(Selling.getStatus().equals("HK"))))
>  {
> 	 segmentFailure.put(new Integer(i), null);
>  }
> }
>
> I want to have a unit test for the conditional statement here without
> using the canned output came from the class Selling.
>

The only thing I can think of is that one effect of adding the second
test method is to call your setUp method twice.  If you leave it with
one test method, but duplicate all the calls in the setUp method, do
you get the same error?  If so, you're on your way.

    David Saff

On 12/6/06, Ole Ersoy <ole_ersoy@...> wrote:
> Hey Guys,
>
> I'm testing a method.
>
> When I have the method by itself it tests fine.
>
> When I put another test in front of it like this:
>         public void testCreateResourceSet()
>         {
>                 //Stub
>                 assertTrue(true);
>         }
>
> I get an exception like this:
> java.lang.ExceptionInInitializerError
>         at
>
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83\
)
>         at
> org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)
>
> ....
>
> I also get the same exception when testing with Maven,
> so I know it is localized to JUnit.
>
> Has anyone else seen behavior like this?
>
> I'll paste the full test case below, in case anyone
> wants to look at it further.
>
> Cheers,
> - Ole
>
>
> package org.jpackage.test;
>
> import java.io.File;
> import java.io.IOException;
>
> import org.apache.maven.artifact.Artifact;
> import
> org.apache.maven.artifact.factory.ArtifactFactory;
> import
> org.apache.maven.artifact.repository.ArtifactRepository;
> import
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
> import
> org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
> import org.apache.maven.plugin.MojoExecutionException;
> import
> org.apache.maven.plugin.testing.AbstractMojoTestCase;
> import org.eclipse.emf.common.util.URI;
> import org.eclipse.emf.ecore.resource.Resource;
> import org.eclipse.emf.ecore.resource.ResourceSet;
> import org.jpackage.impl.JPackageMojoHelperBufferImpl;
> import org.jpackage.impl.JPackageMojoImpl;
> import org.jpackage.JPackageMojoConstants;
> import org.jpackage.impl.JPackageMojoHelperImpl;
>
> import
> com.pyramidetechnologies.emf.utils.EMFUtilities;
>
> public class JPackageMojoHelperTest extends
> AbstractMojoTestCase implements JPackageMojoConstants
> {
>
>         private JPackageMojoImpl mojo = null;
>         private ArtifactRepository artifactRepository = null;
>         private ResourceSet resourceSet = null;
>
>         protected void setUp() throws Exception {
>
>                 // required for mojo lookups to work
>                 super.setUp();
>
>                 File pluginXml = new File(getBasedir(),
>                                 "src/test/resources/plugin-config.xml");
>                 mojo = (JPackageMojoImpl) lookupMojo(
>                                 "xml2spec.mojo",
>                                 "org.jpackage",
>                                 "1.0-SNAPSHOT",
>                                 "generate",
>                                 pluginXml,
>                                 false);
>
>                 resourceSet =
> JPackageMojoHelperImpl.createResourceSet();
>         }
>
>         public void testCreateResourceSet()
>         {
>                 //Stub
>                 assertTrue(true);
>         }
>
>         public void testLoadPomResource() throws
> MojoExecutionException
>         {
>                 String artifactId = "apacheds-server-main";
>                 String groupId = "org.apache.directory.server";
>                 String version = "1.5.0-SNAPSHOT";
>
>                 ArtifactFactory artifactFactory =
> mojo.getArtifactFactory();
>                 assertNotNull(artifactFactory);
>
>                 Artifact pomArtifact =
> artifactFactory.createArtifact(groupId, artifactId,
>                                 version, null, "pom");
>                 assertNotNull(pomArtifact);
>
>                 String path = pathOf(pomArtifact);
>                 File file = new File(path);
>                 assertTrue(file.exists());
>
>                 pomArtifact.setFile(file);
>
>                 Resource resource = null;
>                 resource =
> JPackageMojoHelperImpl.loadPomResource(pomArtifact,
> resourceSet);
>
>                 assertNotNull(resource);
>         }
>
>         private static String pathOf(Artifact artifact)
>         {
>                 ArtifactRepositoryLayout artifactRepositoryLayout =
> new DefaultRepositoryLayout();
>                 String artifactPath =
> artifactRepositoryLayout.pathOf(artifact);
>                 return REPOSITORY_BASE_DIRECTORY + artifactPath;
>         }
>
>         private static String REPOSITORY_BASE_DIRECTORY =
> "/home/ole/.m2/repository/";
>
> }
>
>
>
>
________________________________________________________________________________\
____
> Cheap talk?
> Check out Yahoo! Messenger's low PC-to-Phone call rates.
> http://voice.yahoo.com
>
>
>
> Yahoo! Groups Links
>
>
>
>

Hei Bjorn,

(Norsk?)
Hmmm, good observation!

The ResourceSet that I create in the
setUp likes be inside the test method,
instead of in the setup method.

It contains a set of xml resources that
are loaded using an xml handler.

The XMLHandler looks up metadata
on an EClass, that is a static instance
belonging to an object.

It looks like the eStaticClass() that returns the
object's EClass is unhappy if there is more than a
single instance of ResourceSet in the JVM.

Anyways - That's all the bull I can come up with :-)

I'm really just happy I can test now without loosing
more hair.

Thanks again,
- Ole

--- Björn Gustafsson <bjorng@...> wrote:

> Hi Ole,
>
> I can't tell specifically from your code, but if it
> happens at the
> second test method then it has to do with your
> setUp() method in some
> way.  Do your super.setUp(), lookupMojo() or
> JPackageMojoHelperImpl.createResourceSet() methods
> produce anything
> that requires a reinitialization or teardown after a
> test completes?
> I would guess there is some static state somewhere
> in your abstract
> class or similar that is causing your grief.
>
> mvh,
> Björn
>
> On 12/6/06, Ole Ersoy <ole_ersoy@...> wrote:
> > Hey Guys,
> >
> > I'm testing a method.
> >
> > When I have the method by itself it tests fine.
> >
> > When I put another test in front of it like this:
> >         public void testCreateResourceSet()
> >         {
> >                 //Stub
> >                 assertTrue(true);
> >         }
> >
> > I get an exception like this:
> > java.lang.ExceptionInInitializerError
> >         at
> >
>
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83\
)
> >         at
> >
>
org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)
> >
> > ....
> >
> > I also get the same exception when testing with
> Maven,
> > so I know it is localized to JUnit.
> >
> > Has anyone else seen behavior like this?
> >
> > I'll paste the full test case below, in case
> anyone
> > wants to look at it further.
> >
> > Cheers,
> > - Ole
> >
> >
> > package org.jpackage.test;
> >
> > import java.io.File;
> > import java.io.IOException;
> >
> > import org.apache.maven.artifact.Artifact;
> > import
> > org.apache.maven.artifact.factory.ArtifactFactory;
> > import
> >
>
org.apache.maven.artifact.repository.ArtifactRepository;
> > import
> >
>
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
> > import
> >
>
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
> > import
> org.apache.maven.plugin.MojoExecutionException;
> > import
> >
>
org.apache.maven.plugin.testing.AbstractMojoTestCase;
> > import org.eclipse.emf.common.util.URI;
> > import org.eclipse.emf.ecore.resource.Resource;
> > import org.eclipse.emf.ecore.resource.ResourceSet;
> > import
> org.jpackage.impl.JPackageMojoHelperBufferImpl;
> > import org.jpackage.impl.JPackageMojoImpl;
> > import org.jpackage.JPackageMojoConstants;
> > import org.jpackage.impl.JPackageMojoHelperImpl;
> >
> > import
> > com.pyramidetechnologies.emf.utils.EMFUtilities;
> >
> > public class JPackageMojoHelperTest extends
> > AbstractMojoTestCase implements
> JPackageMojoConstants
> > {
> >
> >         private JPackageMojoImpl mojo = null;
> >         private ArtifactRepository
> artifactRepository = null;
> >         private ResourceSet resourceSet = null;
> >
> >         protected void setUp() throws Exception {
> >
> >                 // required for mojo lookups to
> work
> >                 super.setUp();
> >
> >                 File pluginXml = new
> File(getBasedir(),
> >
> "src/test/resources/plugin-config.xml");
> >                 mojo = (JPackageMojoImpl)
> lookupMojo(
> >                                 "xml2spec.mojo",
> >                                 "org.jpackage",
> >                                 "1.0-SNAPSHOT",
> >                                 "generate",
> >                                 pluginXml,
> >                                 false);
> >
> >                 resourceSet =
> > JPackageMojoHelperImpl.createResourceSet();
> >         }
> >
> >         public void testCreateResourceSet()
> >         {
> >                 //Stub
> >                 assertTrue(true);
> >         }
> >
> >         public void testLoadPomResource() throws
> > MojoExecutionException
> >         {
> >                 String artifactId =
> "apacheds-server-main";
> >                 String groupId =
> "org.apache.directory.server";
> >                 String version = "1.5.0-SNAPSHOT";
> >
> >                 ArtifactFactory artifactFactory =
> > mojo.getArtifactFactory();
> >                 assertNotNull(artifactFactory);
> >
> >                 Artifact pomArtifact =
> > artifactFactory.createArtifact(groupId,
> artifactId,
> >                                 version, null,
> "pom");
> >                 assertNotNull(pomArtifact);
> >
> >                 String path = pathOf(pomArtifact);
> >                 File file = new File(path);
> >                 assertTrue(file.exists());
> >
> >                 pomArtifact.setFile(file);
> >
> >                 Resource resource = null;
> >                 resource =
> >
> JPackageMojoHelperImpl.loadPomResource(pomArtifact,
> > resourceSet);
> >
> >                 assertNotNull(resource);
> >         }
> >
> >         private static String pathOf(Artifact
> artifact)
> >         {
> >                 ArtifactRepositoryLayout
> artifactRepositoryLayout =
> > new DefaultRepositoryLayout();
> >                 String artifactPath =
> > artifactRepositoryLayout.pathOf(artifact);
> >                 return REPOSITORY_BASE_DIRECTORY +
> artifactPath;
> >         }
> >
> >         private static String
> REPOSITORY_BASE_DIRECTORY =
> > "/home/ole/.m2/repository/";
> >
> > }
>




________________________________________________________________________________\
____
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Hi David,

Thanks for the debug tip.  I'll keep that in mind next
time.

I just posted back to Bjorn's reply.

I tested moving resourceSet = ...createResourceSet()
into each test, using several repeated repeated
instances of the same test method, and JUnit is happy.

Thanks again,
- Ole


--- David Saff <saff@...> wrote:

> The only thing I can think of is that one effect of
> adding the second
> test method is to call your setUp method twice.  If
> you leave it with
> one test method, but duplicate all the calls in the
> setUp method, do
> you get the same error?  If so, you're on your way.
>
>    David Saff
>
> On 12/6/06, Ole Ersoy <ole_ersoy@...> wrote:
> > Hey Guys,
> >
> > I'm testing a method.
> >
> > When I have the method by itself it tests fine.
> >
> > When I put another test in front of it like this:
> >         public void testCreateResourceSet()
> >         {
> >                 //Stub
> >                 assertTrue(true);
> >         }
> >
> > I get an exception like this:
> > java.lang.ExceptionInInitializerError
> >         at
> >
>
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83\
)
> >         at
> >
>
org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)
> >
> > ....
> >
> > I also get the same exception when testing with
> Maven,
> > so I know it is localized to JUnit.
> >
> > Has anyone else seen behavior like this?
> >
> > I'll paste the full test case below, in case
> anyone
> > wants to look at it further.
> >
> > Cheers,
> > - Ole
> >
> >
> > package org.jpackage.test;
> >
> > import java.io.File;
> > import java.io.IOException;
> >
> > import org.apache.maven.artifact.Artifact;
> > import
> > org.apache.maven.artifact.factory.ArtifactFactory;
> > import
> >
>
org.apache.maven.artifact.repository.ArtifactRepository;
> > import
> >
>
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
> > import
> >
>
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
> > import
> org.apache.maven.plugin.MojoExecutionException;
> > import
> >
>
org.apache.maven.plugin.testing.AbstractMojoTestCase;
> > import org.eclipse.emf.common.util.URI;
> > import org.eclipse.emf.ecore.resource.Resource;
> > import org.eclipse.emf.ecore.resource.ResourceSet;
> > import
> org.jpackage.impl.JPackageMojoHelperBufferImpl;
> > import org.jpackage.impl.JPackageMojoImpl;
> > import org.jpackage.JPackageMojoConstants;
> > import org.jpackage.impl.JPackageMojoHelperImpl;
> >
> > import
> > com.pyramidetechnologies.emf.utils.EMFUtilities;
> >
> > public class JPackageMojoHelperTest extends
> > AbstractMojoTestCase implements
> JPackageMojoConstants
> > {
> >
> >         private JPackageMojoImpl mojo = null;
> >         private ArtifactRepository
> artifactRepository = null;
> >         private ResourceSet resourceSet = null;
> >
> >         protected void setUp() throws Exception {
> >
> >                 // required for mojo lookups to
> work
> >                 super.setUp();
> >
> >                 File pluginXml = new
> File(getBasedir(),
> >
> "src/test/resources/plugin-config.xml");
> >                 mojo = (JPackageMojoImpl)
> lookupMojo(
> >                                 "xml2spec.mojo",
> >                                 "org.jpackage",
> >                                 "1.0-SNAPSHOT",
> >                                 "generate",
> >                                 pluginXml,
> >                                 false);
> >
> >                 resourceSet =
> > JPackageMojoHelperImpl.createResourceSet();
> >         }
> >
> >         public void testCreateResourceSet()
> >         {
> >                 //Stub
> >                 assertTrue(true);
> >         }
> >
> >         public void testLoadPomResource() throws
> > MojoExecutionException
> >         {
> >                 String artifactId =
> "apacheds-server-main";
> >                 String groupId =
> "org.apache.directory.server";
> >                 String version = "1.5.0-SNAPSHOT";
> >
> >                 ArtifactFactory artifactFactory =
> > mojo.getArtifactFactory();
> >                 assertNotNull(artifactFactory);
> >
> >                 Artifact pomArtifact =
> > artifactFactory.createArtifact(groupId,
> artifactId,
> >                                 version, null,
> "pom");
> >                 assertNotNull(pomArtifact);
> >
> >                 String path = pathOf(pomArtifact);
> >                 File file = new File(path);
> >                 assertTrue(file.exists());
> >
> >                 pomArtifact.setFile(file);
> >
> >                 Resource resource = null;
> >                 resource =
> >
> JPackageMojoHelperImpl.loadPomResource(pomArtifact,
> > resourceSet);
> >
> >                 assertNotNull(resource);
> >         }
> >
> >         private static String pathOf(Artifact
> artifact)
> >         {
> >                 ArtifactRepositoryLayout
> artifactRepositoryLayout =
> > new DefaultRepositoryLayout();
> >                 String artifactPath =
> > artifactRepositoryLayout.pathOf(artifact);
> >                 return REPOSITORY_BASE_DIRECTORY +
> artifactPath;
> >         }
> >
> >         private static String
> REPOSITORY_BASE_DIRECTORY =
> > "/home/ole/.m2/repository/";
> >
> > }
> >
> >
> >
> >
>
________________________________________________________________________________\
____
> > Cheap talk?
> > Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> > http://voice.yahoo.com
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>




________________________________________________________________________________\
____
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

All,

I've been working with Marat Boshernitsan from Agitar over the last
month or so on a way to extend unit testing to include, not just
concrete examples, but general statements about program behavior.  Our
paper "The Practice of Theories" is up:

http://shareandenjoy.saff.net/2006/12/new-paper-practice-of-theories.html

We're very interested in any comments, and especially criticism.  :-)

Comments on the paper in general are probably best posted to the blog
itself.  However, if you'd like to comment on the appropriateness of
including such functionality into JUnit itself, or as a stand-alone
extension, feel free to comment here.

Thanks,

   David Saff