Only if you *choose* to have 100 XML documents or are stuck with a legacy
system that involves 100 XML documents.  There are ways to avoid XML hell.

I've successfully de-sprung a large enterprise application, replacing the
XML with more readable, more tool-friendly Java code.  It made a significant
difference in the speed of system evolution because the team could refactor
much more easily.

--Nat

On 31/07/07, Cédric Beust ♔ <cbeust@...> wrote:
>
>   On 7/30/07, J. B. Rainsberger <jbrains762@...<jbrains762%40gmail.com>>
> wrote:
>
> > It is. If you have 100 XML documents, you're almost certainly doing
> > something wrong.
>
> Isn't this a bit of a hasty judgment?
>
> I'd say that if they have 100 XML documents, they are probably working
> on a midsize enterprise application, and this says absolutely nothing
> about the quality of their code or architecture.
>
> --
> Cédric
> http://testng.org
>
>


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

In my last project we test-drove our Spring wiring. We were highly motivated
to find ways to not create 100 XML documents! ;-)

Paul.

Nat Pryce wrote:
>
>
> Only if you *choose* to have 100 XML documents or are stuck with a legacy
> system that involves 100 XML documents. There are ways to avoid XML hell.
>
> I've successfully de-sprung a large enterprise application, replacing the
> XML with more readable, more tool-friendly Java code. It made a significant
> difference in the speed of system evolution because the team could refactor
> much more easily.
>
> --Nat
>
> On 31/07/07, Cédric Beust ♔ <cbeust@...
> <mailto:cbeust%40google.com>> wrote:
>  >
>  > On 7/30/07, J. B. Rainsberger <jbrains762@...
> <mailto:jbrains762%40gmail.com><jbrains762%40gmail.com>>
>  > wrote:
>  >
>  > > It is. If you have 100 XML documents, you're almost certainly doing
>  > > something wrong.
>  >
>  > Isn't this a bit of a hasty judgment?
>  >
>  > I'd say that if they have 100 XML documents, they are probably working
>  > on a midsize enterprise application, and this says absolutely nothing
>  > about the quality of their code or architecture.
>  >
>  > --
>  > Cédric
>  > http://testng.org <http://testng.org>
>  >
>  >

People need to be told that dependency injection does not require XML.  It's
just a poor way of doing it.

The more I look at Guice, the more I like it.  For me it's one of the first
compelling uses of annotations.  It's more than just the code equivalent of
"tagging."

Michael



-----Original Message-----
From: "Paul King" <paulk@...>
To: junit@yahoogroups.com
Sent: 8/1/2007 8:12 AM
Subject: Re: [junit] Testing singleton patterns


In my last project we test-drove our Spring wiring. We were highly motivated
to find ways to not create 100 XML documents! ;-)

Paul.

Nat Pryce wrote:
>
>
> Only if you *choose* to have 100 XML documents or are stuck with a legacy
> system that involves 100 XML documents. There are ways to avoid XML hell.
>
> I've successfully de-sprung a large enterprise application, replacing the
> XML with more readable, more tool-friendly Java code. It made a significant
> difference in the speed of system evolution because the team could refactor
> much more easily.
>
> --Nat
>
> On 31/07/07, Cédric Beust ♔ <cbeust@...
> <mailto:cbeust%40google.com>> wrote:
>  >
>  > On 7/30/07, J. B. Rainsberger <jbrains762@...
> <mailto:jbrains762%40gmail.com><jbrains762%40gmail.com>>
>  > wrote:
>  >
>  > > It is. If you have 100 XML documents, you're almost certainly doing
>  > > something wrong.
>  >
>  > Isn't this a bit of a hasty judgment?
>  >
>  > I'd say that if they have 100 XML documents, they are probably working
>  > on a midsize enterprise application, and this says absolutely nothing
>  > about the quality of their code or architecture.
>  >
>  > --
>  > Cédric
>  > http://testng.org <http://testng.org>
>  >
>  >

[truncated by sender]

Carfield Yim wrote:

>  > It is. If you have 100 XML documents, you're almost certainly doing
>  > something wrong. The most obvious question I'd ask is "How big is the
>
> Yes, I think in same way, but I still ordered to move more code to XML
> to make it more configurable. Yes, ordered.

OK. It didn't take long to get to the organizational dysfunction in play.

>  > application?" It might be too big and needs to be modularized. Another
>  > question I'd ask is "What do your layers look like?" It might be poorly
>  > layered.
>
> Very likely there are room of improvement. However, I think, if the
> management put configurable as the highest priority, moving most class
> member to XML configuration (spring in our case) . No matter how well
> the modularized / layering, there still a lot of config file and make
> thing more complicate than it should be.

Not necessarily: the more modularized the system, the less complex the
configuration would be. I'm willing to bit there's at least one piece of
configuration information you have to specify in XML that either never
changes or you'd never want to change, but you have to put it there
because something else in the same class needs to be configurable.
That's a sign of the layering problem I have in mind.

>  > Also, why do we need to test our configuration files? I was under the
>  > impression that the goal of externalizing configuration is to make it
>  > /easy/ to change how the application behaves. If that's no longer easy,
>  > we must stop externalizing configuration data and figure out what we're
>  > doing wrong.
>
> Interesting it can be easier in some organization, once the
> application pressed UAT and if some thing required code change, we
> need to complete a number of process like "permit to build" , "user
> approval", "cost estimation" ...... Moving code to config in fact
> provide "hole" to bypassed all those procedures to make quick change.
> And that is the reason why management prefer more config.

Aha! Another organizational dysfunction. They're everywhere! :)

> I can understand, what I think we can improve is there are some
> variable that is just not make sense to be configurable, like change
> the default will break the application, but we still ordered to make
> it configurable just because there are possible to change.....

I would want to learn more about the two organizational problems you
described to me first. Why are you being ordered to do something that
you strongly believe is a bad idea? Why does your team have to create
holes in the design to get around testing? What you describe is a
classic case of trying to solve people problems by changing code. It
doesn't work for long. :)

I sympathize with your position. It's not easy.

> Actually it is off-topic a lot. in fact I just like to make the point
> that IoC framework is not magic and there are cases that using pattern
> like "only create once" is better to make it configurable. In fact, I
> think this case is a lot more than we expect.

I don't know whether it's so off-topic: introducing JUnit into an
organization tends to get people asking more interesting questions. I
see it over and over again.

Back to your comment, of course it's the case: DI containers are no more
magic than any other code. It's also false, though, that DI containers
force you to have 100 XML configuration files. I just wanted to be sure
both sides were represented in the discussion.

Good luck... I mean that.
--
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

Cédric Beust ♔ wrote:

> On 7/30/07, J. B. Rainsberger <jbrains762@...
> <mailto:jbrains762%40gmail.com>> wrote:
>
>  > It is. If you have 100 XML documents, you're almost certainly doing
>  > something wrong.
>
> Isn't this a bit of a hasty judgment?

Yes, but that doesn't make it wrong. Have you read "Blink"?

> I'd say that if they have 100 XML documents, they are probably working
> on a midsize enterprise application, and this says absolutely nothing
> about the quality of their code or architecture.

To claim it says /nothing/ about their code or architecture is just
plain naive. Just as it would be to claim it's /definitely/ a problem.
That's why I said /almost/. The bottom line is that most projects are
too big, and especially most "midsize enterprise application"s are too
big, by which I mean that they're much more often than not treated as
big blobs of stuff, rather than side-by-side, loosely coupled modules
that work when you put them together.

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 wrote:
> Cédric Beust ♔ wrote:
>  > Isn't this a bit of a hasty judgment?
>
> Yes, but that doesn't make it wrong.

I don't want to get into the middle of such esteemed folks, but
I'm boggled by the move to XML instead of Java.

With Java, we can hope to use tools like JUnit.
With XML, maybe we can, maybe we can't.

>  > I'd say that if they have 100 XML documents,

> To claim it says /nothing/ about their code or architecture is just
> plain naive.

We can give the poster the benefit of the doubt, but 100 XML documents
sure would imply to me hundreds of Java classes, and perhaps hundreds of
JSPs, javascripts, etc.

Anything that big is going to take serious testing. Not only the unit
testing that JUnit can help on, but GUI testing, button clicking and all
sorts of ugly stuff.



> The bottom line is that most projects are
> too big, and especially most "midsize enterprise application"s are too
> big, by which I mean that they're much more often than not treated as
> big blobs of stuff, rather than side-by-side, loosely coupled modules
> that work when you put them together.

I'm biased towards "Better, Faster, Lighter Java"
as a philosophy, but I'm not sure it is practical.
Some applications are just big, slow, and ugly.

I think that a fair number of magic numbers and parameters would be
easier to edit, check, and use if they were written in Java code.
Singleton or not. Its not like editing big XML files is something you
should do in Notepad.

Just IMHO, of course.

--
Pat Farrell
http://www.pfarrell.com/

On 7/28/07, Cédric Beust ♔ <cbeust@...> wrote:
> The gain can be summarized as follows.
>
> Hard to test:
>
> public void query() {
>   Database.query("...");
> }
>
> Easy to test:
>
> public void query(Database db) {
>   db.query("...");
> }

I'm late to the conversation, but that's a model of brief clarity.
Thanks, Cedric.

    David Saff

P.S.  Yes, I meant it.

Thanks, David, glad you like it.

It's actually pretty much the first slide of my presentation "Designing for
Testability".

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


On 8/1/07, David Saff <saff@...> wrote:
>
>   On 7/28/07, Cédric Beust ♔ <cbeust@... <cbeust%40google.com>>
> wrote:
> > The gain can be summarized as follows.
> >
> > Hard to test:
> >
> > public void query() {
> > Database.query("...");
> > }
> >
> > Easy to test:
> >
> > public void query(Database db) {
> > db.query("...");
> > }
>
> I'm late to the conversation, but that's a model of brief clarity.
> Thanks, Cedric.
>
> David Saff
>
> P.S. Yes, I meant it.
>
>


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

>  OK. It didn't take long to get to the organizational dysfunction in play.
>

Hard to say it is dysfunction. In term of income, it is definitely
functional, this is a company earn a lot and probably everyone know
the name.

>  Not necessarily: the more modularized the system, the less complex the
>  configuration would be. I'm willing to bit there's at least one piece of
>  configuration information you have to specify in XML that either never
>  changes or you'd never want to change, but you have to put it there
>  because something else in the same class needs to be configurable.
>  That's a sign of the layering problem I have in mind.
>
There are 2 examples I come to my mind immediately.
1) We have a factory that hold the reference of all repositories in a
map. That map is configurable with difference implementation:

	 <bean id="concurrentHashMap"
		 class="java.util.concurrent.ConcurrentHashMap" singleton="false" />

2) All data access object ( map DB column names to getter and setter
only, no single logic, i.e.
http://martinfowler.com/bliki/AnemicDomainModel.html ) , have
interfaces and inject by spring.

I cannot think of any other implmentation for the above 2 cases,
probably better layering will help, but above is definitely
over-engineering in my point of view.

>  Aha! Another organizational dysfunction. They're everywhere! :)
>

Well.... we have to follow the policy :-/

>  I would want to learn more about the two organizational problems you
>  described to me first. Why are you being ordered to do something that
>  you strongly believe is a bad idea? Why does your team have to create
>  holes in the design to get around testing? What you describe is a
>  classic case of trying to solve people problems by changing code. It
>  doesn't work for long. :)
>
>  I sympathize with your position. It's not easy.
>

Actually may be my tone is too strong, people are nice and the order
is just a stronger tone of recommendation from my supervior. I just
join this company and now I start to build up some creditability and
probably I can affect some design decision later.

>  I don't know whether it's so off-topic: introducing JUnit into an
>  organization tends to get people asking more interesting questions. I
>  see it over and over again.
>

Actually there are some junit tests that created before but now most
of the are commented out like

public void testXXX() {
/**
....
....
*/
}

Because they are already not compilable and no one bother to fix it.
It is a long way to persuade developer to write and maintain
unit-test. :-/

>  Back to your comment, of course it's the case: DI containers are no more
>  magic than any other code. It's also false, though, that DI containers
>  force you to have 100 XML configuration files. I just wanted to be sure
>  both sides were represented in the discussion.
>
>  Good luck... I mean that.

Yes, I need luck ;-)

I've just thought of another categorisation of tests: whether they are
regression tests or work in progress.

We write tests for the functionality to be delivered in the upcoming
iteration.  Those tests will initially fail.  As we go through the iteration
more and more of them will pass as we complete the work.  However, we can't
let the failing tests stop us checking in changes.  So we categorise tests
as "work-in-progress" or "regression".  Work-in-progress tests are allowed
to fail without breaking the CI build.  A failing regression test breaks the
build and must be fixed immediately before further changes can be checked
in.

At the end of the iteration, passing "work-in-progress" tests are
recategorised as regression tests.If new work requires changes to existing
functionality, the regression tests for that  functionality are
recategorised as "work-in-progress" until the new work is done.

At the moment we just move tests between different source folders.  That
works smoothly enough.

--Nat

On 26/07/07, Kent Beck <kentb@...> wrote:
>
>   All,
>
> It seems clear to me that some sort of test classification scheme is a
> reasonable thing to add to JUnit. However, rather than simply copy one of
> the models out there we're going to go back to first principles and try to
> derive a model for classification that is concise, useful, flexible, and,
> above all, easy to use.
>
> I've heard two purposes for classification:
> * Performance
> * Assumptions
>
> Performance
>
> If you have tests that run for longer than your attention span (my limits
> are 1 second for the inner loop of programming and 10 minutes for
> integration), running a subset of the tests can give you some assurance
> that
> the software is working. Classification is one way to reduce test run
> time--just this one test, all tests in this class, all tests in this
> package, all tests labeled "quick", etc.
>
> There are other ways of reducing test run time. For example, you could
> have
> a runner that runs 1 second worth of the tests that have failed most
> recently or a runner that runs half a second of recently failed tests plus
> half a second of randomly selected tests.
>
> In the end I think the systemic solution to test run times is to improve
> design and testing techniques to dramatically increase the assurance/CPU
> cycle ratio.
>
> I remember a friend's story of an early project that used tests
> extensively.
> After three years they had a carefully tuned suite that took ten minutes
> to
> run. When the test runtime increased beyond ten minutes, they would work
> on
> the design of the system and/or the design of the tests to improve the
> assurance/CPU cycle ratio and get the runtime back under ten minutes. Then
> most of the original team left.
>
> A few years later my friend was shown the system. The programmer proudly
> explained that the test suites now took 24 hours to run, even though the
> system had grown little in functionality. They had stopped paying
> attention
> to designing for testability. Every time they added a new axis of
> variability they blindly ran the cross product of the existing tests with
> all the alternatives for the new axis. Yes they had more tests, but A/C
> had
> dropped by several orders of magnitude.
>
> In short, I see using classification to reduce test runtime as a bandage
> masking the real problem which is low A/C. Using classification to reduce
> test runtime really is a hack and I hope people will continue working to
> improve design for testability. We will still provide some classification
> mechanism, but that doesn't make it not a hack.
>
> Assumptions
>
> The second reason I've heard for classification is to avoid a slew of
> misleadingly failing tests. If my development machine doesn't have access
> to
> the database, then if I run the database tests I'll get a bunch of
> failures
> even though the system is really working (or, to be more precise, I don't
> have any information about whether the system is really working or not).
>
> Classification is one way to express assumptions. When I say "@Test(groups
> =
> {"database"})" I have declared something about this test. However, this
> expression seems limited and error-prone to me. I'd prefer to have the
> power
> of a programming language to express my assumptions.
>
> In the JUnit 4.4 you can use assumeThat() to express assumptions. For
> example, you can say:
>
> public class DatabaseTest {
> @BeforeClass public static void isDatabaseAccessible() {
> User result= Database.login("kent");
> assumeThat(not(isError(result));
> }
> ...
> }
>
> This is a bit of a workaround because runner don't yet handle failed
> assumptions as anything other than successful tests, but it gives you a
> richer language to express assumptions than a textual classification
> scheme.
>
> The Point
>
> So now the point of this long post. Are there other uses of classification
> that I've missed? Is the above way of expressing assumptions (or something
> derived from it like an explicit @Assumption) sufficient?
>
> Regards,
>
> Kent Beck
> Three Rivers Institute
>
> [Non-text portions of this message have been removed]
>
>
>


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

Pat Farrell wrote:

> J. B. Rainsberger wrote:
>  > Cédric Beust ♔ wrote:
>  > > Isn't this a bit of a hasty judgment?
>  >
>  > Yes, but that doesn't make it wrong.
>
> I don't want to get into the middle of such esteemed folks, but
> I'm boggled by the move to XML instead of Java.
>
> With Java, we can hope to use tools like JUnit.
> With XML, maybe we can, maybe we can't.

XML is fine, if we limit ourselves to data. Once we start writing code,
Java is more up to the task than XML is.

<snip />

>  > The bottom line is that most projects are
>  > too big, and especially most "midsize enterprise application"s are too
>  > big, by which I mean that they're much more often than not treated as
>  > big blobs of stuff, rather than side-by-side, loosely coupled modules
>  > that work when you put them together.
>
> I'm biased towards "Better, Faster, Lighter Java"
> as a philosophy, but I'm not sure it is practical.
> Some applications are just big, slow, and ugly.

I find that to be a cop-out, in general. Applications are how we design
them, purely and simply.

> I think that a fair number of magic numbers and parameters would be
> easier to edit, check, and use if they were written in Java code.
> Singleton or not. Its not like editing big XML files is something you
> should do in Notepad.

This is close to my point: if it's not something we can confidently
change without re-testing the entire application, it shouldn't be
externalized configuration data, it should be code. I'm not convinced
that the choice of implementations of interfaces is configuration data.
I think the community has lost its way on the difference between
configuring applications and wiring objects together.

> Just IMHO, of course.

All opinions welcome. :)
--
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

An Applet is just a Panel so it can be tested like any GUI component.

--Nat

On 30/07/07, jason r tibbetts <tibbettj@...> wrote:
>
>   Vivek,
>
> > On 7/27/07, vivekvembu <vivekvembu@... <vivekvembu%40yahoo.com>
> > <mailto:vivekvembu% <vivekvembu%25>40yahoo.com>> wrote:
> > > I tried using JUnit to open an Applet, and do Code Coverage, but
> > > nothing seem to work.
> > >
> > > It would be great if anyone provide me some information on how to test
> > > Java Applets using JUnit and do Code Coverage using EMMA.
> >
> > Could describe what you did in a bit more detail? The thing is,
> > getting code coverage of your unit tests happens the same way
> > regardless of whether it's an applet or a web application: you tell
> > your coverage tool to instrument the production code, you run the
> > tests, and you ask the coverage tool to generate a pretty report that
> > you can look at.
>
> The OP may be asking how to get JUnit to launch an applet in order to
> test it. My advice is to make the applet nothing more than a lightweight
> wrapper around a collection of Swing components that can be tested in
> the usual way. The applet class itself would remain untested, but that's
> an acceptable sacrifice.
>
> If the OP is asking how to test GUI components, that's an entirely
> separate discussion.
>
>
>


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

On 02/08/07, J. B. Rainsberger <jbrains762@...> wrote:
>  If it's not something we can confidently
>  change without re-testing the entire application, it shouldn't be
>  externalized configuration data, it should be code. I'm not convinced
>  that the choice of implementations of interfaces is configuration data.
>  I think the community has lost its way on the difference between
>  configuring applications and wiring objects together.

This is a good article about finding this balance:

     http://worsethanfailure.com/Articles/Soft_Coding.aspx

--Nat

Nat Pryce wrote:

>On 02/08/07, J. B. Rainsberger <jbrains762@...> wrote:
>
>
>> If it's not something we can confidently
>> change without re-testing the entire application, it shouldn't be
>> externalized configuration data, it should be code. I'm not convinced
>> that the choice of implementations of interfaces is configuration data.
>> I think the community has lost its way on the difference between
>> configuring applications and wiring objects together.
>>
>>
>
>This is a good article about finding this balance:
>
>    http://worsethanfailure.com/Articles/Soft_Coding.aspx
>
>--Nat
>
>
>
Very cool article, but the name 'Soft Coding' seems a little too
pleasant :-)

Michael Feathers

On 02/08/2007, Nat Pryce <nat.pryce@...
<mailto:nat.pryce@...> > wrote:

>>  We write tests for the functionality to be delivered in the upcoming
>>  iteration. Those tests will initially fail. As we go through the
iteration
>>  more and more of them will pass as we complete the work. However, we
can't
>>  let the failing tests stop us checking in changes. So we categorise
tests
>>  as "work-in-progress" or "regression". Work-in-progress tests are
allowed
>>  to fail without breaking the CI build.

I realise that this is a JUnit list not a TDD one, but how does Writing
Lots Of Tests Upfront differ from BDUF?

Cheers, APC



A P Clarke
Software Architect
LogicaCMG UK Public Sector Division
Stephenson House
75 Hampstead Road
London
UK
NW1 2PL
Direct Tel: +44 (0)207 446 4006
Fax: +44 (0)207 446 1352
Email: andrew.clarke@...




<http://geo.yahoo.com/serv?s=97359714/grpId=2423328/grpspId=1705006905/m
sgId=19687/stime=1186071555/nc1=4507179/nc2=3848546/nc3=3848642>



This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential information
and/or be subject to legal privilege. It should not be copied, disclosed to,
retained or used by, any other party. If you are not an intended recipient then
please promptly delete this e-mail and any attachment and all copies and inform
the sender. Thank you.


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

End-to-end tests are not "design". They part are the requirements spec and
so writing them is analysis work.  They specify acceptance criteria for a
particular piece of work (User Story in XP-speak).

We write end-to-end tests for the upcoming iteration only and use them for
tracking progress through that iteration.

On our current project, the developers write the end-to-end tests before
implementing them to make them pass.  We're hoping to change that over
time.  On my last project a BA, tester and developer would cooperate to
write acceptance tests for a story as part of the analysis so that the tests
would be ready for when the development team started work on the story and
it worked pretty well, so we'd like to introduce that way of working on our
current project but there's some way to go yet.

Actually on that project we didn't call them "tests". We called them
"specs". It just happened that the specs were in a format that allowed them
to be automatically validated.

--Nat

On 03/08/07, Clarke, Andrew <Andrew.Clarke@...> wrote:
>
>   On 02/08/2007, Nat Pryce <nat.pryce@... <nat.pryce%40gmail.com>
> <mailto:nat.pryce@... <nat.pryce%40gmail.com>> > wrote:
>
> >> We write tests for the functionality to be delivered in the upcoming
> >> iteration. Those tests will initially fail. As we go through the
> iteration
> >> more and more of them will pass as we complete the work. However, we
> can't
> >> let the failing tests stop us checking in changes. So we categorise
> tests
> >> as "work-in-progress" or "regression". Work-in-progress tests are
> allowed
> >> to fail without breaking the CI build.
>
> I realise that this is a JUnit list not a TDD one, but how does Writing
> Lots Of Tests Upfront differ from BDUF?
>
> Cheers, APC
>
>
>
> A P Clarke
> Software Architect
> LogicaCMG UK Public Sector Division
> Stephenson House
> 75 Hampstead Road
> London
> UK
> NW1 2PL
> Direct Tel: +44 (0)207 446 4006
> Fax: +44 (0)207 446 1352
> Email: andrew.clarke@... <andrew.clarke%40logicacmg.com>
>
> <http://geo.yahoo.com/serv?s=97359714/grpId=2423328/grpspId=1705006905/m
> sgId=19687/stime=1186071555/nc1=4507179/nc2=3848546/nc3=3848642>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
> [Non-text portions of this message have been removed]
>
>
>


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

Hi frnds,

I am new to this group.my name is Ramath, located in kerala,India.
  can u tell me how can we pass the argument from build.xml to my
testClass.I dont find any attributes like args as in Java task.
  my junit task looks likes :->


<target name="test" depends="compile">
      <junit fork="yes" haltonfailure="yes">
     	     <formatter type="plain" usefile="false" />
	     <classpath refid="build.classpath" />
	      <batchtest>
             <fileset dir="${build}" includes="**/InValidXmlTest.class"/>
		 </batchtest>
       </junit>
</target>

Hello Sarath,

On 8/4/07, sarath.ramath <sarath.ramath@...> wrote:
>  I am new to this group.my name is Ramath, located in kerala,India.
>   can u tell me how can we pass the argument from build.xml to my
>  testClass.I dont find any attributes like args as in Java task.

There is no way to pass command line arguments to JUnit test classes.
What you can do is use the system property and JVM argument
configurations described in the documentation
(http://ant.apache.org/manual/OptionalTasks/junit.html).

Lasse

--
Lasse Koskela
* Author of "Test Driven" (Manning Publications, 2007) *
* Reaktor Innovations * http://www.ri.fi/en *

Is it possible to use JUnit to test servlets and related things?
Clearly I'll have to mock up some requests, but I'm not having
much luck even getting started.

I'm getting NoClassDefErrors at runtime for the usual javax things, such as
javax.servlet.http.HttpServletRequest

I would expect the tests to fail, at least until I learn to mock up the
objects properly, but I would have thought that the usual classes would
be available.

I'm using NetBeans 5.5 driving JDK 1.6 on linux, if that makes a difference.

Hints, pointers, links, etc. appreciated.

Pat

--
Pat Farrell
http://www.pfarrell.com/

Nat Pryce wrote:

> On 02/08/07, J. B. Rainsberger <jbrains762@...
> <mailto:jbrains762%40gmail.com>> wrote:
>  > If it's not something we can confidently
>  > change without re-testing the entire application, it shouldn't be
>  > externalized configuration data, it should be code. I'm not convinced
>  > that the choice of implementations of interfaces is configuration data.
>  > I think the community has lost its way on the difference between
>  > configuring applications and wiring objects together.
>
> This is a good article about finding this balance:
>
> http://worsethanfailure.com/Articles/Soft_Coding.aspx
> <http://worsethanfailure.com/Articles/Soft_Coding.aspx>

Thanks, Nat; I've read that one. Part of the problem is that
configuration is in the eye of the beholder, and vision strength varies
wildly. :)
--
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

Pat Farrell wrote:

> Is it possible to use JUnit to test servlets and related things?
> Clearly I'll have to mock up some requests, but I'm not having
> much luck even getting started.
>
> I'm getting NoClassDefErrors at runtime for the usual javax things, such as
> javax.servlet.http.HttpServletRequest
>
> I would expect the tests to fail, at least until I learn to mock up the
> objects properly, but I would have thought that the usual classes would
> be available.
>
> I'm using NetBeans 5.5 driving JDK 1.6 on linux, if that makes a difference.
>
> Hints, pointers, links, etc. appreciated.

_JUnit Recipes_, chapter 12.
--
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

Hi Pat,

On 8/5/07, J. B. Rainsberger <jbrains762@...> wrote:
> Pat Farrell wrote:
>  > Is it possible to use JUnit to test servlets and related things?
>  > Clearly I'll have to mock up some requests, but I'm not having
>  > much luck even getting started.
>  >
>  > I'm getting NoClassDefErrors at runtime for the usual javax things, such as
>  > javax.servlet.http.HttpServletRequest
>
>  _JUnit Recipes_, chapter 12.

Or _Test Driven_, chapter 5. However, I don't think you need a recipe
for testing Servlets as such. The NoClassDefError indicates there's
something flaky about your "test" class path. I don't know anything
about NetBeans, though, so I cannot really provide any concrete help
there.

Lasse

--
Lasse Koskela
* Author of "Test Driven" (Manning Publications, 2007) *
* Reaktor Innovations * http://www.ri.fi/en *

J. B. Rainsberger wrote:
> Pat Farrell wrote:
>  > Hints, pointers, links, etc. appreciated.
>
> _JUnit Recipes_, chapter 12.

I'm not against buying books, I have over 40 O'Reilly books.
But is the content of this online anywhere? Try before buy, etc.

--
Pat Farrell
http://www.pfarrell.com/

The Jetty servlet container can be easily started/stopped in a JUnit test
and you can pass it a servlet object to run rather than a WAR file to load.

I try to isolate my application code from the servlet or webapp framework
API itself.  I test code that uses the API directly in end-to-end or
integration tests by starting it up in Jetty and then making HTTP requests
from JUnit.  I'll test-drive the application code that is isolated from the
servlet API the usual way by using JUnit asserts and jMock mocks where
appropriate.

I don't recommend mocking the servlet APIs themselves.

--Nat

On 05/08/07, Pat Farrell <pfarrell@...> wrote:
>
>   Is it possible to use JUnit to test servlets and related things?
> Clearly I'll have to mock up some requests, but I'm not having
> much luck even getting started.
>
> I'm getting NoClassDefErrors at runtime for the usual javax things, such
> as
> javax.servlet.http.HttpServletRequest
>
> I would expect the tests to fail, at least until I learn to mock up the
> objects properly, but I would have thought that the usual classes would
> be available.
>
> I'm using NetBeans 5.5 driving JDK 1.6 on linux, if that makes a
> difference.
>
> Hints, pointers, links, etc. appreciated.
>
> Pat
>
> --
> Pat Farrell
> http://www.pfarrell.com/
>
>
>


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

On Sun, 05 Aug 2007 17:42:05 +0200, Pat Farrell <pfarrell@...>
wrote:

> J. B. Rainsberger wrote:
>> Pat Farrell wrote:
>>  > Hints, pointers, links, etc. appreciated.
>>
>> _JUnit Recipes_, chapter 12.
>
> I'm not against buying books, I have over 40 O'Reilly books.
> But is the content of this online anywhere? Try before buy, etc.

Have a look at http://www.manning.com/rainsberger/


--
Stein Erik Berget

Pat Farrell wrote:

> J. B. Rainsberger wrote:
>  > Pat Farrell wrote:
>  > > Hints, pointers, links, etc. appreciated.
>  >
>  > _JUnit Recipes_, chapter 12.
>
> I'm not against buying books, I have over 40 O'Reilly books.
> But is the content of this online anywhere? Try before buy, etc.

I believe if you Google the book, you can find a sample chapter or two
posted as publicity when we first released it. Also, I occasionally give
out sample chapters upon request when I really like the requester. :)

Sadly, it's not on Safari. I don't know why.

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

Stein Erik Berget wrote:

> On Sun, 05 Aug 2007 17:42:05 +0200, Pat Farrell <pfarrell@...
> <mailto:pfarrell%40pfarrell.com>>
> wrote:
>
>  > J. B. Rainsberger wrote:
>  >> Pat Farrell wrote:
>  >> > Hints, pointers, links, etc. appreciated.
>  >>
>  >> _JUnit Recipes_, chapter 12.
>  >
>  > I'm not against buying books, I have over 40 O'Reilly books.
>  > But is the content of this online anywhere? Try before buy, etc.
>
> Have a look at http://www.manning.com/rainsberger/
> <http://www.manning.com/rainsberger/>

Right. Those are the introductory chapter and the chapter on XML.
--
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

Nat Pryce wrote:
>
>
> The Jetty servlet container can be easily started/stopped in a JUnit test
> and you can pass it a servlet object to run rather than a WAR file to load.
>
> I try to isolate my application code from the servlet or webapp framework
> API itself. I test code that uses the API directly in end-to-end or
> integration tests by starting it up in Jetty and then making HTTP requests
> from JUnit. I'll test-drive the application code that is isolated from the
> servlet API the usual way by using JUnit asserts and jMock mocks where
> appropriate.
>
> I don't recommend mocking the servlet APIs themselves.

Exactly. It's the same advice as for EJBs: push your code out into plain
Java objects, then have the servlet or EJB invoke your code. Leave the
JNDI calls and other container integration in the container component;
push everything else out into plain Java. It's the best balance I've
found so far.

Jetty is a great way to drive a wedge into existing servlet code so you
can refactor it more safely.

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

Lasse Koskela wrote:
>  The NoClassDefError indicates there's
> something flaky about your "test" class path. I don't know anything
> about NetBeans, though, so I cannot really provide any concrete help
> there.

Yes, of course the javax.servlet classes are missing.
NetBeans includes tomcat, so that is the "container" that resolves the
classes when executing.

Its not clear, at least to me, which .jar file includes them. If I knew
that, I could add them to the library path for testing.

Clearly testing POJOs is easier, but some classes, naturally seem
to want to be tested in the "container" context.


--
Pat Farrell
http://www.pfarrell.com/

If you add an embeddable servlet container (e.g. Jetty) to your project,
it's JARs will incude the Servlet API.  It's usually in servlet.jar or
javax.servlet.jar or something like that, sometimes in j2ee.jar or
javaee.jar.

--Nat

On 06/08/07, Pat Farrell <pfarrell@...> wrote:
>
>   Lasse Koskela wrote:
> > The NoClassDefError indicates there's
> > something flaky about your "test" class path. I don't know anything
> > about NetBeans, though, so I cannot really provide any concrete help
> > there.
>
> Yes, of course the javax.servlet classes are missing.
> NetBeans includes tomcat, so that is the "container" that resolves the
> classes when executing.
>
> Its not clear, at least to me, which .jar file includes them. If I knew
> that, I could add them to the library path for testing.
>
> Clearly testing POJOs is easier, but some classes, naturally seem
> to want to be tested in the "container" context.
>
> --
> Pat Farrell
> http://www.pfarrell.com/
>
>
>


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