On Thu, 2005-04-07 at 02:57, balakrishna_narla wrote:
>
> Hi,
>      I've just started working with JUnit. Till now i've written some
> testcases and executing these testcases with the help of a testsuite.
> Now i want to execute a test case based upon the input provided by
> the
> user and i want to have this input as a parameter to the testcase. Is
> it possible to pass parameters to the testcase. If so please help me
> out with some sample code.

You can Google for "Parameterized Test Case" or search the archives for
it.  You will find lots of information.

   * --
     Jason Rogers

     "I am crucified with Christ: nevertheless I live; yet not I,
     but Christ liveth in me: and the life which I now live in
     the flesh I live by the faith of the Son of God, who loved
     me, and gave himself for me."
         Galatians 2:20

balakrishna_narla wrote:
>
>
> Hi,
>      I've just started working with JUnit. Till now i've written some
> testcases and executing these testcases with the help of a testsuite.
> Now i want to execute a test case based upon the input provided by
> the
> user and i want to have this input as a parameter to the testcase. Is
> it possible to pass parameters to the testcase. If so please help me
> out with some sample code.

_JUnit Recipes_, recipe 4.8.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

Arun J wrote:
> Folks,
>
> I have a heirarchy of test cases.(jUnit/cactus based).  Some test
> cases are run at the parent level and some are run at the child level.
> My observation is this. When I run my child test cases it traverses
> to the parent and runs the parent's tests also.  My question is this..
>
> #1. Can I stop my derived Unit tests from running parent tests.?

Yes: collect the tests yourself with suite().

> #2. If I cannot stop them, can I run them in a specific order so that
> parent tests and then child tests..?  One I could think of is add them
> to the Test Suite in every derived Uts.

You could use GSBase's OrderedTestSuite.

A bigger question: if you don't want to inherit the tests, then why have
one test case class inherit from another? If it's to share utility
features, then I recommend pushing those out to another class that both
can use.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

noam_eitan wrote:

> 1. I not going to argue about the MVC thing :), the app is adding data
> to the session, so, a given action can access it.
> now, I can try to set up all the info in the testXXX method, the prob
> is that I'm re-writing the app in the test env :(( .

If you want to test the action, then I recommend coding it in a way that
the important behavior doesn't know that data is in the session. Example:

MyAction {
      perform(request, response) {
          Object value = request.getSession(false).getAttribute("name");
          reallyDoIt(request, response, value);
      }

      // Real logic here
      reallyDoIt(request, response, value) {
          ... now use value ....
      }
}

You can test the reallyDoIt() method -- which contains all the logic you
really want to test -- without having to put data in the session.
Instead, just pass different "value"s for the different conditions you
want to test. You can test perform() if you want, but it will only break
if something else doesn't put a value in the session under "name". Test
/that/ thing instead. As written, perform() can't really fail on its own
-- it's Too Simple to Break.

For now, I recommend you focus on getting the logic right. Once the
defect rate in that part of the code is low, spend time learning how to
test the integration points between the J2EE framework and your logic.

> 2. for me "how can I test a scenario" sounds like a common q. aren't
> other developers what to check it , and not only a specific action ?

It might be a common question, but I don't know what you mean, so I
don't know what to recommend. "Scenario" is one of those common words
that has 20 different meanings when you ask 20 different people what it
means.

> 3. I will check the other framework u mentioned.

I think it will help. Good luck.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

Thanks folks for your inputs.  Lots of discomfort using jUnit, is it
only me..:-(

Though this is not my usecase. Do not get carried away by this
example..I am trying to sample a similar one..
Assume the following heirarchy structure..
BizDoc = Performs versions/history relation functions.
OrderDoc -> BizDoc = Performs Order related functions.
RequestDoc -> BizDoc = Performs Request related functions.
PurchaseOrder ->OrderDoc = Performs PO specific functions.
Invoice -> OrderDoc = Performs Invoice specific functions.
Shipment -> Orderdoc = Performs Shipment specific functions.
Auction -> RequestDoc = Performs auctions specific functions.
PurchaseRequest -> RequestDoc = Performs PR specific functions.

I would prefer to organize my tests with a similar hierarchy structure
to test the functions at the respective level.  Also I would like to
initialise the objects needed in the appropriate level for the childs
to make use of them without doing them again.

Currently when PurchaseRequestUt and AuctionUt tests are run, it
executes RequestDocUt tests as well BizDocUt tests twice which is
unnecessary.

I see two options .
1. Have a single parent without testXXX methods do the on demand
initialisation at the top level and all Uts inherit from this single
parent. And have Uts in a single level. In the above case BizDocUt &
PurchaseRequestUt will be in the same level.  BizDocUt initialises
some objects in the helpers and make available for all Uts.  Or if
PurchaseRequestUt is run first it initialises first all Bizdoc objects
so that BizdocUt can run w/o initializing them again.

2. Maintain the heirarchy of Ut and use the Test suite in all Ut
classes to add the child tests only.

Guys - don't you feel this is a very common need for any OO
application.  I am surprised JUnit doesn't provided this flexibility
directly.  I have posted my requirement for Logical flow of tests
which is also good to have.  JUnit has these missing.  I can
hack(override) into jUnit to support these but I do not want to
maintain this for every release.

JUnit folks..are you hearing...?

~JAK
On Apr 8, 2005 1:04 AM, J. B. Rainsberger <jbrains@...> wrote:
>  Arun J wrote:
>  > Folks,
>  >
>  > I have a heirarchy of test cases.(jUnit/cactus based).  Some test
>  > cases are run at the parent level and some are run at the child level.
>  > My observation is this. When I run my child test cases it traverses
>  > to the parent and runs the parent's tests also.  My question is this..
>  >
>  > #1. Can I stop my derived Unit tests from running parent tests.?
>
>  Yes: collect the tests yourself with suite().
>
>  > #2. If I cannot stop them, can I run them in a specific order so that
>  > parent tests and then child tests..?  One I could think of is add them
>  > to the Test Suite in every derived Uts.
>
>  You could use GSBase's OrderedTestSuite.
>
>  A bigger question: if you don't want to inherit the tests, then why have
>  one test case class inherit from another? If it's to share utility
>  features, then I recommend pushing those out to another class that both
>  can use.
>  --
>  J. B. (Joe) Rainsberger
>  Diaspar Software Services
>  http://www.diasparsoftware.com
>  Author, JUnit Recipes: Practical Methods for Programmer Testing
>
>
>  ________________________________
>  Yahoo! Groups Links
>
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/junit/
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
,,,,,      Arunkumar Jayaraman
( ',')      mail.jak@...
<|"|>    Work: +91-80-51988318
_/"|_    Mobile: +91-9845283731

Arun J wrote:

> Though this is not my usecase. Do not get carried away by
> this example..I am trying to sample a similar one.. Assume
> the following heirarchy structure..
> BizDoc = Performs versions/history relation functions.
> OrderDoc -> BizDoc = Performs Order related functions.
> RequestDoc -> BizDoc = Performs Request related functions.
> PurchaseOrder ->OrderDoc = Performs PO specific functions.
> Invoice -> OrderDoc = Performs Invoice specific functions.
> Shipment -> Orderdoc = Performs Shipment specific functions.
> Auction -> RequestDoc = Performs auctions specific functions.
> PurchaseRequest -> RequestDoc = Performs PR specific functions.

With all due respect, this hierarchy looks a little big to me. I would think
about using composition in some of those places. (Or aren't you actually
talking about inheritance here?)

> I would prefer to organize my tests with a similar hierarchy
> structure

Why?

> Also I would like to initialise the objects needed in the
> appropriate level for the childs to make use of them without doing
> them again.

I'm not sure I understand this. Care to elaborate?

> 1. Have a single parent without testXXX methods do the on
> demand initialisation at the top level and all Uts inherit
> from this single parent. And have Uts in a single level. In
> the above case BizDocUt & PurchaseRequestUt will be in the
> same level.  BizDocUt initialises some objects in the helpers
> and make available for all Uts.  Or if PurchaseRequestUt is
> run first it initialises first all Bizdoc objects so that
> BizdocUt can run w/o initializing them again.

So are you saying the Bizdoc objects are global to the tests? What does it
mean to "initialize" them? Where are the hold?

> 2. Maintain the heirarchy of Ut and use the Test suite in all
> Ut classes to add the child tests only.

Sounds like unecessary work to me.

> Guys - don't you feel this is a very common need for any OO
> application.

Frankly, no, I don't feel it is. It rather looks to me as if your design is
suboptimal, and that your testing problems are just a symptom of that. I
don't know enough to be sure, though.

> I am surprised JUnit doesn't provided this
> flexibility directly.

That's because the inventors of Junit, and many of it users, don't just
write unit tests to tests the system, but use writing tests as a *design*
technique. If they encounter a problem when trying to write Junit tests for
their system, they first think about what the system needed to look like to
not have those problems, and often find that refactoring it to that
direction improves the overall decoupling and flexibility.

> I have posted my requirement for
> Logical flow of tests which is also good to have.  JUnit has these
> missing.

It can be added to Junit without a problem, it is flexible enough to allow
that. It's not at the core of Junit because many of its users actually think
that needing a "Logical flow of tests" is a thing that should be avoided.

> I can hack(override) into jUnit to support these but I do
> not want to maintain this for every release.

If you want, you can write a TestSuite implementation that uses reflection
to only call the test methods declared directly in a class (that is, not the
inherited ones). I think it would take me less than an hour to do so. In
years of using Junit, I never felt the need to do that, though.

> JUnit folks..are you hearing...?

Certainly. Are you, too? ;)

Take care, Ilja

Thanks for taking time..find my response inline.

On Apr 8, 2005 12:22 PM, Ilja Preuss <preuss@...> wrote:
>  Arun J wrote:
>
>  > Though this is not my usecase. Do not get carried away by
>  > this example..I am trying to sample a similar one.. Assume
>  > the following heirarchy structure..
>  > BizDoc = Performs versions/history relation functions.
>  > OrderDoc -> BizDoc = Performs Order related functions.
>  > RequestDoc -> BizDoc = Performs Request related functions.
>  > PurchaseOrder ->OrderDoc = Performs PO specific functions.
>  > Invoice -> OrderDoc = Performs Invoice specific functions.
>  > Shipment -> Orderdoc = Performs Shipment specific functions.
>  > Auction -> RequestDoc = Performs auctions specific functions.
>  > PurchaseRequest -> RequestDoc = Performs PR specific functions.
>
>  With all due respect, this hierarchy looks a little big to me. I would
> think
>  about using composition in some of those places. (Or aren't you actually
>  talking about inheritance here?)

JAK: as I have mentioned this heirarchy is just a sample...in reality
it could be even deeper.  Let us not question the design for testing..

>  > I would prefer to organize my tests with a similar hierarchy
>  > structure
>
>  Why?
>
>  > Also I would like to initialise the objects needed in the
>  > appropriate level for the childs to make use of them without doing
>  > them again.
>
>  I'm not sure I understand this. Care to elaborate?
hmm. There won't a limit to explain the situation.  I assume you
understand the scenario i'm trying to explain.  At different levels it
looks up and initializes the composite objects for that level.
Derivatives uses them sometimes or overrides depending on their needs.

>  > 1. Have a single parent without testXXX methods do the on
>  > demand initialisation at the top level and all Uts inherit
>  > from this single parent. And have Uts in a single level. In
>  > the above case BizDocUt & PurchaseRequestUt will be in the
>  > same level.  BizDocUt initialises some objects in the helpers
>  > and make available for all Uts.  Or if PurchaseRequestUt is
>  > run first it initialises first all Bizdoc objects so that
>  > BizdocUt can run w/o initializing them again.
>
>  So are you saying the Bizdoc objects are global to the tests? What does it
>  mean to "initialize" them? Where are the hold?
>
BizDoc is the System object and BizDocUt is Unit test class which
tests the BizDoc operations/API. Here Parent(s) can have any name
which extends TestCase and BizDocUt and other tests would inherit and
use them as just parents .  These parent(s) will not have testXXX
methods.
>  > 2. Maintain the heirarchy of Ut and use the Test suite in all
>  > Ut classes to add the child tests only.
>
>  Sounds like unecessary work to me.
This is an alternative to override the default behavior of the jUnit
which adds parents test also.  I agree this is painful but it is
necessary.
>  > Guys - don't you feel this is a very common need for any OO
>  > application.
>
>  Frankly, no, I don't feel it is. It rather looks to me as if your design is
>  suboptimal, and that your testing problems are just a symptom of that. I
>  don't know enough to be sure, though.
>
System design is for meeting the requirement not meeting the testing
requirement.
When we are writing test cases at the lower level (API testing) we
can't expect a seperate set of API for testing purpose only.

>  > I am surprised JUnit doesn't provided this
>  > flexibility directly.
>
>  That's because the inventors of Junit, and many of it users, don't just
>  write unit tests to tests the system, but use writing tests as a *design*
>  technique. If they encounter a problem when trying to write Junit tests for
>  their system, they first think about what the system needed to look like to
>  not have those problems, and often find that refactoring it to that
>  direction improves the overall decoupling and flexibility.
>
>  > I have posted my requirement for
>  > Logical flow of tests which is also good to have.  JUnit has these
>  > missing.
>
>  It can be added to Junit without a problem, it is flexible enough to allow
>  that. It's not at the core of Junit because many of its users actually
> think
>  that needing a "Logical flow of tests" is a thing that should be avoided.
>
>  > I can hack(override) into jUnit to support these but I do
>  > not want to maintain this for every release.
>
>  If you want, you can write a TestSuite implementation that uses reflection
>  to only call the test methods declared directly in a class (that is, not
> the
>  inherited ones). I think it would take me less than an hour to do so. In
>  years of using Junit, I never felt the need to do that, though.
>
I understand you have not encountered this before and that is the
reason why I have explained a scenario which needs this.  It is not
about writing some code to override the behaviour, it is about
maintaining them..

>  > JUnit folks..are you hearing...?
>
>  Certainly. Are you, too? ;)

Thanks..I mean jUnit inventors in your language..:-)

~JAK

Arun J wrote:

> JAK: as I have mentioned this heirarchy is just a sample...in
> reality it could be even deeper.

Don't know what "JAK" means, and acronymfinder doesn't either... :o

Anyway, in my opinion it already is too deep for a sound OO design.

> Let us not question the design for
> testing..

Why not? I find it to be very valuable to do so.

Anyway, if you don't want to question the design, I think we already
provided solutions to make it possible with Junit. As it's not the preferred
way of working for many Junit users, I think it's reasonable that the
solution isn't part of Junit's core.

> At
> different levels it looks up and initializes the composite objects
> for that level. Derivatives uses them sometimes or overrides
> depending on their needs.

I see two issues here:

First, objects are complex. The general advice here is to simplify them. Use
composition to build a complex web of objects to provide complex behaviour.
In your unit tests, don't write many tests for the complex web, but for
simple objects it is composed of. Where an object in the web needs to
collaborate with other objects in the web, in your unit tests replace them
with stub/mock implementations.

Or, if you think you can't do that, google for the Object Mother pattern.

Second, I understood you to say that you are reusing objects between tests,
so only the first test using an object would instantiate it, the following
would reuse it. Generally, this is a big no-no in unit testing, and I'd like
to understand why you think you need to do it.


>>  So are you saying the Bizdoc objects are global to the tests? What
>> does it  mean to "initialize" them? Where are the hold?
>>
> BizDoc is the System object and BizDocUt is Unit test class
> which tests the BizDoc operations/API. Here Parent(s) can
> have any name which extends TestCase and BizDocUt and other
> tests would inherit and use them as just parents .  These
> parent(s) will not have testXXX methods.

I don't feel that this answers my question. Perhaps my writings above help
you understand where my question is coming from...

>>  Frankly, no, I don't feel it is. It rather looks to me as if your
>> design is  suboptimal, and that your testing problems are just a
>> symptom of that. I  don't know enough to be sure, though.
>>
> System design is for meeting the requirement not meeting the
> testing requirement. When we are writing test cases at the
> lower level (API testing) we can't expect a seperate set of API for
> testing purpose only.

Not a separate API. What I'm saying is that many people experience that
making the API testable improves the design in general. With other words,
meeting unit testing requirements is a great help in meeting the general
requirement of producing a flexible and extensible design.

>>  If you want, you can write a TestSuite implementation that uses
>> reflection  to only call the test methods declared directly in a
>> class (that is, not the  inherited ones). I think it would take me
>> less than an hour to do so. In  years of using Junit, I never felt
>> the need to do that, though.
>>
> I understand you have not encountered this before and that is
> the reason why I have explained a scenario which needs this.

Let me clarify: I certainly encountered code that was hard to test using
Junit. My solution until now always was to improve the code, not to extend
Junit, though. And I wholeheartedly think it was the better solution.

Cheers, Ilja

Redirected to Junit list...

Arun J wrote:

> JAK is my name...J ArunKumar..I'm not so popular so you
> cannot find me in the acronym finder.;-)  Thanks again for taking
> time on this.

OK... :)


> "Where an object in the web needs to
>>  collaborate with other objects in the web, in your unit tests
>> replace them  with stub/mock implementations."
>
> True..and that is the first approach and that what I am
> doing...leaving the deep inheritance, provide a mock
> implementation parent and test different level through multiple tests.
>
>>  Second, I understood you to say that you are reusing objects between
>> tests,  so only the first test using an object would instantiate it,
>> the following  would reuse it. Generally, this is a big no-no in unit
>> testing, and I'd like  to understand why you think you need to do it.
>
> I do a lookup and use those managers to initialise some
> objects.  And I do not want to lookup managers again and
> again to initialize these objects everytime for use.  As long
> as behavior of these lookups and initialization doesn't
> change over different Unit tests I do not see why it should be a
> no-no..

I still don't understand why you'd have more than one test class be
dependent on those lookups at all. Sounds like a kind of coupling I wouldn't
want to have.

If you aren't worried about it, you can initiliaze those objects once using
a TestSetup decorator, though. And again, take a look at the Object Mother
pattern.

>>  Let me clarify: I certainly encountered code that was hard to test
>> using  Junit. My solution until now always was to improve the code,
>> not to extend  Junit, though. And I wholeheartedly think it was the
>> better solution.
>
> We can debate this forever.   To what extent we should support
> testability..? I hope you concur we should stop at some level.

I'm not interested in a debate. I'm interested in discussion, though, in
learning about the experiences of others, and in providing my experience to
those who are interested in it.

If nothing else, my reasoning might explain to you why Junit is the way it
is, why it doesn't out of the box support the type of testing you are
requesting, which you seemed to be curious about. If you really think you
need to do that kind of testing and are not interested in discussing
alternatives, that's fine with me. In my experience Junit is flexible enough
to provide that kind of testing, too, as an extension.

And to provide an answer to your very first question in this thread: the
pain you are experiencing seems to mainly come from the fact that you want
to use Junit differently from how most of its other users use and advocate
it.

Take care, Ilja

Hi,

I have used JTestCase for a while (http://jtestcase.sourceforge.net/) but then
we decided to hard code the parameters because there was no need for a lot of
test data flexibility...There are examples on the JTestCase website for using
this framework...

--Klaus Berg



junit@yahoogroups.com schrieb am 07.04.05 21:35:05:

balakrishna_narla wrote:
>
>
> Hi,
>      I've just started working with JUnit. Till now i've written some
> testcases and executing these testcases with the help of a testsuite.
> Now i want to execute a test case based upon the input provided by
> the
> user and i want to have this input as a parameter to the testcase. Is
> it possible to pass parameters to the testcase. If so please help me
> out with some sample code.

_JUnit Recipes_, recipe 4.8.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing


__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

I need to test a class in which all the methods read via System.in.

How can I fake the input so that I can automate my tests ?

Any answer will be helpfull ..... I am using JUnit under Eclipse.


================================================================

class Input {

   static final BufferedReader keyboard = new BufferedReader( new
InputStreamReader(System.in));

   static int readInt()  throws IOException {
  	 // I1
     return new Integer (keyboard.readLine().trim() ).intValue() ;
   }

   static double readDouble()  throws IOException{
  	 // I2
     return new Double (keyboard.readLine().trim() ).doubleValue() ;
   }

   static double[] readDoubleLine()  throws IOException  {
  	 // I3
     StringTokenizer dline = new StringTokenizer (keyboard.readLine()) ;
     double[] values = new double[dline.countTokens()] ;
     for (int i = 0 ; i < values.length ; i++ ) // T4
     {
    		 // I5
    		 values[i] = new Double (dline.nextToken()).doubleValue() ;
     }
       // I6
     return values ;
   }

   static int[] readIntLine()  throws IOException  {
  	 // I7
     StringTokenizer iline = new StringTokenizer (keyboard.readLine()) ;
     int[] values = new int[iline.countTokens()] ;
     for (int i = 0 ; i < values.length ; i++ ) // I8
     {
    		 // I9
          values[i] = Integer.parseInt (iline.nextToken()) ;
     }
     // I10
     return values ;
   }

   static char[] readCharLine()  throws IOException {
  	 // I11
     String cline = keyboard.readLine() ;
     char[] values = new char[cline.length()] ;
     cline.getChars(0,cline.length(),values,0);
     return values ;
   }

   static String readString() throws IOException {
  	 // I12
     return keyboard.readLine();
   }

}

Arun J wrote:

> Thanks folks for your inputs.  Lots of discomfort using jUnit, is it
> only me..:-(
>
> Though this is not my usecase. Do not get carried away by this
> example..I am trying to sample a similar one..
> Assume the following heirarchy structure..
> BizDoc = Performs versions/history relation functions.
> OrderDoc -> BizDoc = Performs Order related functions.
> RequestDoc -> BizDoc = Performs Request related functions.
> PurchaseOrder ->OrderDoc = Performs PO specific functions.
> Invoice -> OrderDoc = Performs Invoice specific functions.
> Shipment -> Orderdoc = Performs Shipment specific functions.
> Auction -> RequestDoc = Performs auctions specific functions.
> PurchaseRequest -> RequestDoc = Performs PR specific functions.
>
> I would prefer to organize my tests with a similar hierarchy structure
> to test the functions at the respective level.  Also I would like to
> initialise the objects needed in the appropriate level for the childs
> to make use of them without doing them again.

If you only want to share common setup (common objects), then put that
behavior in the setUp() method of an abstract TestCase class, then have
all related test case classes extend that.

To speak in terms of your example, don't have OrderDoc extend BizDoc.
Instead, have each extend BizOrderRequestDocTestTemplate, which is
abstract and has no test cases.

I think your discomfort comes from using inheritance in a way JUnit did
not intend.

> Currently when PurchaseRequestUt and AuctionUt tests are run, it
> executes RequestDocUt tests as well BizDocUt tests twice which is
> unnecessary.

... so don't extend a class containing tests!

> I see two options .
> 1. Have a single parent without testXXX methods do the on demand
> initialisation at the top level and all Uts inherit from this single
> parent. And have Uts in a single level. In the above case BizDocUt &
> PurchaseRequestUt will be in the same level.  BizDocUt initialises
> some objects in the helpers and make available for all Uts.  Or if
> PurchaseRequestUt is run first it initialises first all Bizdoc objects
> so that BizdocUt can run w/o initializing them again.

Yes! You'd be working the way JUnit is designed.

> Guys - don't you feel this is a very common need for any OO
> application.

Absolutely not. In fact, wanting to use the same setup for so many
different tests is a design smell. Well-designed OO code doesn't need this.

> I am surprised JUnit doesn't provided this flexibility
> directly.  I have posted my requirement for Logical flow of tests
> which is also good to have.

It's good to have when you choose to test an application end to end,
rather than testing objects individually. JUnit was designed to help
testing objects, not end-to-end application request/response cycles.

> JUnit has these missing.  I can
> hack(override) into jUnit to support these but I do not want to
> maintain this for every release.

I strongly recommend tools like Fit or TestNG for end-to-end testing,
and use JUnit when you want to test individual objects.

> JUnit folks..are you hearing...?

Yes. Now it's time for you to hear: stop using inheritance this way.
It's obviously not helping you, so do something else. Perhaps what a
number of us have recommended already. (At least three times, if I count
correctly.)
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

Arun J wrote:

> On Apr 8, 2005 12:22 PM, Ilja Preuss <preuss@...> wrote:
>  >  Arun J wrote:
>  >
>  >  > Though this is not my usecase. Do not get carried away by
>  >  > this example..I am trying to sample a similar one.. Assume
>  >  > the following heirarchy structure..
>  >  > BizDoc = Performs versions/history relation functions.
>  >  > OrderDoc -> BizDoc = Performs Order related functions.
>  >  > RequestDoc -> BizDoc = Performs Request related functions.
>  >  > PurchaseOrder ->OrderDoc = Performs PO specific functions.
>  >  > Invoice -> OrderDoc = Performs Invoice specific functions.
>  >  > Shipment -> Orderdoc = Performs Shipment specific functions.
>  >  > Auction -> RequestDoc = Performs auctions specific functions.
>  >  > PurchaseRequest -> RequestDoc = Performs PR specific functions.
>  >
>  >  With all due respect, this hierarchy looks a little big to me. I would
>  > think
>  >  about using composition in some of those places. (Or aren't you actually
>  >  talking about inheritance here?)
>
> JAK: as I have mentioned this heirarchy is just a sample...in reality
> it could be even deeper.  Let us not question the design for testing..

The design /is/ the point of the discussion. If you're not interested in
discussing that, then please stop. If the hierarchy were even deeper,
that would only show a worse design problem.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

rubbinio wrote:
>
>
> I need to test a class in which all the methods read via System.in.
>
> How can I fake the input so that I can automate my tests ?

Right now you're using a BufferedReader that talks to System.in. If you
had a BufferedReader that talks to a StringReader, then you could fake
all the input using Strings.

Right now you're hardcoding the value of "keyboard" for each instance of
the class Input. You could introduce a parameter so that:
   * your tests could pass in a StringReader
   * your production code could pass in the InputStreamReader talking to
System.in

Step 1: Change everything in Input so it's no longer static.
Step 2: Introduce this constructor:

public class Input(Reader source) {
      this.keyboard = new BufferedReader(source);
}

Step 3: Consider renaming "keyboard" since it's no longer talking
(necessarily) to a keyboard.

Now, to use your class, write code like this:

Input keyboardInput = new Input(new InputStreamReader(System.in));

In your tests, write code like this:

testReadInt() {
      Input input = new Input(new StringReader("26\n"));
      assertEquals(26, input.readInt());
}

This is a specific example of refactoring code so that it doesn't depend
directly on global data (System.in). In general, it's a good idea not to
depend directly on global data.

I hope this helped.
\--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

>
> I need to test a class in which all the methods read via System.in.
>
> How can I fake the input so that I can automate my tests ?
>
> Any answer will be helpfull ..... I am using JUnit under Eclipse.
>
>
> ================================================================
>
> class Input {
>
>   static final BufferedReader keyboard = new BufferedReader( new
> InputStreamReader(System.in));
>

Since JDK1.1, there is a method
	 System.setIn(InputStream in)
Just call this in setUp() to get Input from somewhere else (a
FileInputStream or a ByteArrayInputStream probably make most sense). If
you want to be perfect, do the following:

class MyTestCase ... {
   InputStream originalIn;
   public void setUp() {
     originalIn = System.in;
     System.setIn(....);
   }
   public void tearDown() {
     System.setIn(originalIn);
   }
   // ...
}

No need for any fancy refactoring ;-) - but it wouldn't hurt to do it!

Regards
Harald M. Mueller

Thx Harald for your answer but I managed to find a solution myself
after a loot of seraching on the net and a lot of reading I came up
with my own solution. Here it is in case someone else needs it.

I basically created a thread which fakes an input and it works great.
Here is the code:


private class fakeInput extends Thread
     {
         private String in_;

         public fakeInput( String in )
         {
             in_ = in;
         }

         public void run()
         {
             try
             {

                 PipedInputStream testInPipe = new PipedInputStream();
            	 PipedOutputStream testOutPipe = new PipedOutputStream();
            	 testInPipe.connect(testOutPipe);
            	 System.setIn(testInPipe);
            	 String withline = in_ + "\n";
                 this.sleep(1000);
                 testOutPipe.write(withline.getBytes(), 0,
withline.length());


             }
             catch ( Exception e)
             {
             }


         }
     }


--- In junit@yahoogroups.com, Harald M. Muller <harald.m.mueller@b...>
wrote:
>
> >
> > I need to test a class in which all the methods read via System.in.
> >
> > How can I fake the input so that I can automate my tests ?
> >
> > Any answer will be helpfull ..... I am using JUnit under Eclipse.
> >
> >
> > ================================================================
> >
> > class Input {
> >
> >   static final BufferedReader keyboard = new BufferedReader( new
> > InputStreamReader(System.in));
> >
>
> Since JDK1.1, there is a method
>  System.setIn(InputStream in)
> Just call this in setUp() to get Input from somewhere else (a
> FileInputStream or a ByteArrayInputStream probably make most sense). If
> you want to be perfect, do the following:
>
> class MyTestCase ... {
>   InputStream originalIn;
>   public void setUp() {
>     originalIn = System.in;
>     System.setIn(....);


>   }
>   public void tearDown() {
>     System.setIn(originalIn);
>   }
>   // ...
> }
>
> No need for any fancy refactoring ;-) - but it wouldn't hurt to do it!
>
> Regards
> Harald M. Mueller

Unfortunatelly I can not change the code as this was an Assignemnt in
a Quality Assurance course and the trick was to find a way to test it
as it is.

--- In junit@yahoogroups.com, "J. B. Rainsberger" <jbrains@r...> wrote:
> rubbinio wrote:
> >
> >
> > I need to test a class in which all the methods read via System.in.
> >
> > How can I fake the input so that I can automate my tests ?
>
> Right now you're using a BufferedReader that talks to System.in. If you
> had a BufferedReader that talks to a StringReader, then you could fake
> all the input using Strings.
>
> Right now you're hardcoding the value of "keyboard" for each
instance of
> the class Input. You could introduce a parameter so that:
>   * your tests could pass in a StringReader
>   * your production code could pass in the InputStreamReader talking to
> System.in
>
> Step 1: Change everything in Input so it's no longer static.
> Step 2: Introduce this constructor:
>
> public class Input(Reader source) {
>      this.keyboard = new BufferedReader(source);
> }
>
> Step 3: Consider renaming "keyboard" since it's no longer talking
> (necessarily) to a keyboard.
>
> Now, to use your class, write code like this:
>
> Input keyboardInput = new Input(new InputStreamReader(System.in));
>
> In your tests, write code like this:
>
> testReadInt() {
>      Input input = new Input(new StringReader("26\n"));
>      assertEquals(26, input.readInt());
> }
>
> This is a specific example of refactoring code so that it doesn't
depend
> directly on global data (System.in). In general, it's a good idea
not to
> depend directly on global data.
>
> I hope this helped.
> \--
> J. B. (Joe) Rainsberger
> Diaspar Software Services
> http://www.diasparsoftware.com
> Author, JUnit Recipes: Practical Methods for Programmer Testing

hi.

thanks for your reply.

let me tell u what I mean by the word "scenario".

the user is doing the following steps, and I want to check the whole
process :
1. the user is logging in. the servlet is then check the user/pass,
and save the user profile info in the session.
2. the user is locating some data, lets say "workers". he types a
worker name. the servlet is getting the data from the DB, but before
the selecting, it checks that the user, (as saved in the session) has
the authorization to do so. after selecting the "worker/workers", the
servlet is saving them in the session.
3. the user is asking to display some data of the "workers". the
servlet is again checking the authorization to do the action, and the
authorization  to check about those "workers" (all the info is coming
from the session).

now, if I want to check this scenario, by checking only the last
step, I have to init the user data and the "workers" data in the
session, and then to invoke the last step. what I want to do is to
invoke steps 1,2 and when invoking the last one, all the data will be
in the session.

how can I do so ?

thanks.

Well - you did use the System.setIn() as I explained. For the rest,
using the pipe mechanism is of course also possible and ok, it is
only more work than simply providing a ByteInputStream by the two
lines

    byte[] withLine = in.getBytes();
    System.setIn(new ByteArrayInputStream(withLine));

... and off you go, without need of Threads, sleeps, Exceptions, and
other things.
Keep it simple :-)

Regards
Harald M. Mueller

--- In junit@yahoogroups.com, "rubbinio" <rubbinio@y...> wrote:
>
> Thx Harald for your answer but I managed to find a solution myself
> after a loot of seraching on the net and a lot of reading I came up
> with my own solution. Here it is in case someone else needs it.
>
> I basically created a thread which fakes an input and it works
great.
> Here is the code:
>
>
> private class fakeInput extends Thread
>     {
>         private String in_;
>
>         public fakeInput( String in )
>         {
>             in_ = in;
>         }
>
>         public void run()
>         {
>             try
>             {
>
>                 PipedInputStream testInPipe = new PipedInputStream
();
>              PipedOutputStream testOutPipe = new PipedOutputStream
();
>              testInPipe.connect(testOutPipe);
>              System.setIn(testInPipe);
>              String withline = in_ + "\n";
>                 this.sleep(1000);
>                 testOutPipe.write(withline.getBytes(), 0,
> withline.length());
>
>
>             }
>             catch ( Exception e)
>             {
>             }
>
>
>         }
>     }
>
>
> --- In junit@yahoogroups.com, Harald M. Muller
<harald.m.mueller@b...>
> wrote:
> >
> > >
> > > I need to test a class in which all the methods read via
System.in.
> > >
> > > How can I fake the input so that I can automate my tests ?
> > >
> > > Any answer will be helpfull ..... I am using JUnit under
Eclipse.
> > >
> > >
> > >
================================================================
> > >
> > > class Input {
> > >
> > >   static final BufferedReader keyboard = new BufferedReader(
new
> > > InputStreamReader(System.in));
> > >
> >
> > Since JDK1.1, there is a method
> >  System.setIn(InputStream in)
> > Just call this in setUp() to get Input from somewhere else (a
> > FileInputStream or a ByteArrayInputStream probably make most
sense). If
> > you want to be perfect, do the following:
> >
> > class MyTestCase ... {
> >   InputStream originalIn;
> >   public void setUp() {
> >     originalIn = System.in;
> >     System.setIn(....);
>
>
> >   }
> >   public void tearDown() {
> >     System.setIn(originalIn);
> >   }
> >   // ...
> > }
> >
> > No need for any fancy refactoring ;-) - but it wouldn't hurt to
do it!
> >
> > Regards
> > Harald M. Mueller

You have two basic approaches: perform an "integration
test" or a "unit test with stubs/mocks".

With an integration test you walk your application through
all of the previous steps. If you do it frequently enough
you can refactor those bits out into some common fixtures
or utility libraries. E.g. in your example below you could
put the code for steps 1 and 2 in a setUp method. This can
usually be done without changing the application under test
but can sometimes be slow and may make your tests more fragile,
e.g. if the application changes for steps 1 and 2, you might
have to change your test even though you are testing step 3.

With the unit test approach, you set up mock or stub classes.
In your case, you could (as an example) set up a session stub
which had hard-coded inside it all of the required data as
it would be after steps 1 and 2. This may require a little
bit of refactoring initially if the original application
wasn't designed with mock/stub objects in mind but the
tests will run faster and in general be less fragile.
You can write your own stubs or use jmock, easymock,
mockrunner or other equivalent packages.

Paul.

noam_eitan wrote:
>
> hi.
>
> thanks for your reply.
>
> let me tell u what I mean by the word "scenario".
>
> the user is doing the following steps, and I want to check the whole
> process :
> 1. the user is logging in. the servlet is then check the user/pass,
> and save the user profile info in the session.
> 2. the user is locating some data, lets say "workers". he types a
> worker name. the servlet is getting the data from the DB, but before
> the selecting, it checks that the user, (as saved in the session) has
> the authorization to do so. after selecting the "worker/workers", the
> servlet is saving them in the session.
> 3. the user is asking to display some data of the "workers". the
> servlet is again checking the authorization to do the action, and the
> authorization  to check about those "workers" (all the info is coming
> from the session).
>
> now, if I want to check this scenario, by checking only the last
> step, I have to init the user data and the "workers" data in the
> session, and then to invoke the last step. what I want to do is to
> invoke steps 1,2 and when invoking the last one, all the data will be
> in the session.
>
> how can I do so ?
>
> thanks.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

IIja/Joe,

Thanks folks..Now I have a (kind of) flat structure for tests..with
one abstract parent without any testXXX under which all tests would
be.  My hierachical requirement is moved out as hierarchical helpers
that are creating test objects (similar to ObjectMother pattern
suggested by IIja).. how does it sound..?

>>Let us not question the design for testing..

I didn't mean to be rude here.  But I wanted to imply that the app
design is done this way for various reasons.  But the tests has to be
written around the existing app design.  The issue in question was the
test design not the app design.

~JAK

On Apr 10, 2005 12:01 AM, J. B. Rainsberger <jbrains@...> wrote:
>  Arun J wrote:
>
>  > On Apr 8, 2005 12:22 PM, Ilja Preuss <preuss@...> wrote:
>  >  >  Arun J wrote:
>  >  >
>  >  >  > Though this is not my usecase. Do not get carried away by
>  >  >  > this example..I am trying to sample a similar one.. Assume
>  >  >  > the following heirarchy structure..
>  >  >  > BizDoc = Performs versions/history relation functions.
>  >  >  > OrderDoc -> BizDoc = Performs Order related functions.
>  >  >  > RequestDoc -> BizDoc = Performs Request related functions.
>  >  >  > PurchaseOrder ->OrderDoc = Performs PO specific functions.
>  >  >  > Invoice -> OrderDoc = Performs Invoice specific functions.
>  >  >  > Shipment -> Orderdoc = Performs Shipment specific functions.
>  >  >  > Auction -> RequestDoc = Performs auctions specific functions.
>  >  >  > PurchaseRequest -> RequestDoc = Performs PR specific functions.
>  >  >
>  >  >  With all due respect, this hierarchy looks a little big to me. I
> would
>  >  > think
>  >  >  about using composition in some of those places. (Or aren't you
> actually
>  >  >  talking about inheritance here?)
>  >
>  > JAK: as I have mentioned this heirarchy is just a sample...in reality
>  > it could be even deeper.  Let us not question the design for testing..
>
>  The design /is/ the point of the discussion. If you're not interested in
>  discussing that, then please stop. If the hierarchy were even deeper,
>  that would only show a worse design problem.
>  --
>  J. B. (Joe) Rainsberger
>  Diaspar Software Services
>  http://www.diasparsoftware.com
>  Author, JUnit Recipes: Practical Methods for Programmer Testing
>

Arun J wrote:

> Thanks folks..Now I have a (kind of) flat structure for
> tests..with one abstract parent without any testXXX under
> which all tests would be.  My hierachical requirement is
> moved out as hierarchical helpers that are creating test
> objects (similar to ObjectMother pattern suggested by IIja).. how
> does it sound..?

Doesn't sound ideal, but like it's probably the best you can do if you don't
want to touch the app's design.

>>> Let us not question the design for testing..
>
> I didn't mean to be rude here.

No rudeness implied. Still, please notice that not wanting to question the
app's design when encountering testing problems is unlikely to lead to
optimal results. Problems in test design most often just are a result of
suboptimal app design.

> But I wanted to imply that
> the app design is done this way for various reasons.

Certainly. I'd bet, though, that it's possible to find a design that
conforms to both the needs of testing and those other reasons, and that most
experienced OO developers would say that such a design is better.

> But the
> tests has to be written around the existing app design.  The
> issue in question was the test design not the app design.

Then the issue is how to write unit tests for a suboptimally designed app. I
hope you can now understand why Junit doesn't strive to support that very
well out of the box - most Junit practitioners simply prefer to improve the
app's design in those cases.

Cheers, Ilja

Ilja Preuss wrote:

>Arun J wrote:
>
>
>
>>Thanks folks..Now I have a (kind of) flat structure for
>>tests..with one abstract parent without any testXXX under
>>which all tests would be.  My hierachical requirement is
>>moved out as hierarchical helpers that are creating test
>>objects (similar to ObjectMother pattern suggested by IIja).. how
>>does it sound..?
>>
>>
>
>Doesn't sound ideal, but like it's probably the best you can do if you don't
>want to touch the app's design.
>
>
>
>>>>Let us not question the design for testing..
>>>>
>>>>
>>I didn't mean to be rude here.
>>
>>
>
>No rudeness implied. Still, please notice that not wanting to question the
>app's design when encountering testing problems is unlikely to lead to
>optimal results. Problems in test design most often just are a result of
>suboptimal app design.
>
>
>
>>But I wanted to imply that
>>the app design is done this way for various reasons.
>>
>>
>
>Certainly. I'd bet, though, that it's possible to find a design that
>conforms to both the needs of testing and those other reasons, and that most
>experienced OO developers would say that such a design is better.
>
>
>
>>But the
>>tests has to be written around the existing app design.  The
>>issue in question was the test design not the app design.
>>
>>
>
>Then the issue is how to write unit tests for a suboptimally designed app. I
>hope you can now understand why Junit doesn't strive to support that very
>well out of the box - most Junit practitioners simply prefer to improve the
>app's design in those cases.
>
>Cheers, Ilja
>

Indeed.  Its always tricky adding unit tests to existing code - made
even harder when that existing code is sub optimally designed.  It would
be worth Arun getting a copy of Micheal feathers book - 'Working
Effectively With Legacy Code' .

One of the important aspects Micheal has identified when retro fitting
tests, is that sometimes the code will have to be made even more
suboptimal to allow testing.  However, once its tested, we can then
start to refactor the design in a safer manner.

http://www.objectmentor.com/resources/articles/beforeClarity.pdf

well.. the app code is neither legacy nor a 'untouchable' piece.  If
there is a design flaw, we can change it but that is not the case
here.  Becoz jUnit does not support inheritance for testing the app
which has deep heierarchy one wouldn't want to change the design.  But
the points that came out of this discussion were good. I would
summarize it soon so that it would be beneficial for others..

~JAK

On Apr 11, 2005 3:43 PM, Andrew McDonagh <andrew.mcdonagh@...> wrote:
>
>  Ilja Preuss wrote:
>
>  >Arun J wrote:
>  >
>  >
>  >
>  >>Thanks folks..Now I have a (kind of) flat structure for
>  >>tests..with one abstract parent without any testXXX under
>  >>which all tests would be.  My hierachical requirement is
>  >>moved out as hierarchical helpers that are creating test
>  >>objects (similar to ObjectMother pattern suggested by IIja).. how
>  >>does it sound..?
>  >>
>  >>
>  >
>  >Doesn't sound ideal, but like it's probably the best you can do if you
> don't
>  >want to touch the app's design.
>  >
>  >
>  >
>  >>>>Let us not question the design for testing..
>  >>>>
>  >>>>
>  >>I didn't mean to be rude here.
>  >>
>  >>
>  >
>  >No rudeness implied. Still, please notice that not wanting to question the
>  >app's design when encountering testing problems is unlikely to lead to
>  >optimal results. Problems in test design most often just are a result of
>  >suboptimal app design.
>  >
>  >
>  >
>  >>But I wanted to imply that
>  >>the app design is done this way for various reasons.
>  >>
>  >>
>  >
>  >Certainly. I'd bet, though, that it's possible to find a design that
>  >conforms to both the needs of testing and those other reasons, and that
> most
>  >experienced OO developers would say that such a design is better.
>  >
>  >
>  >
>  >>But the
>  >>tests has to be written around the existing app design.  The
>  >>issue in question was the test design not the app design.
>  >>
>  >>
>  >
>  >Then the issue is how to write unit tests for a suboptimally designed app.
> I
>  >hope you can now understand why Junit doesn't strive to support that very
>  >well out of the box - most Junit practitioners simply prefer to improve
> the
>  >app's design in those cases.
>  >
>  >Cheers, Ilja
>  >
>
>  Indeed.  Its always tricky adding unit tests to existing code - made
>  even harder when that existing code is sub optimally designed.  It would
>  be worth Arun getting a copy of Micheal feathers book - 'Working
>  Effectively With Legacy Code' .
>
>  One of the important aspects Micheal has identified when retro fitting
>  tests, is that sometimes the code will have to be made even more
>  suboptimal to allow testing.  However, once its tested, we can then
>  start to refactor the design in a safer manner.
>
> http://www.objectmentor.com/resources/articles/beforeClarity.pdf
>
>
>
>  ________________________________
>  Yahoo! Groups Links
>
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/junit/
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
,,,,,      Arunkumar Jayaraman
( ',')      mail.jak@...
<|"|>    Work: +91-80-51988318
_/"|_    Mobile: +91-9845283731

Arun J wrote:

>well.. the app code is neither legacy nor a 'untouchable' piece.  If
>there is a design flaw, we can change it but that is not the case
>here.  Becoz jUnit does not support inheritance for testing the app
>which has deep heierarchy one wouldn't want to change the design.  But
>the points that came out of this discussion were good. I would
>summarize it soon so that it would be beneficial for others..
>
>~JAK
>
>
Sorry, I should have explained a bit more...

By 'legacy' we simply mean code that is not covered by unit tests, not
code that is old.

I've been reading this thread, but what do you mean when you say
'support inheritance for testing the app which has deep hierarchy'?

if we have the following:

class Base {}
class Intermediate extends Base{}

class FirstMostDerived extends Intermediate {}
class SecondMostDerived extends Intermediate {}

Then there is a large inheritance tree here.  Yet even so, JUnit can
easily test this.

Good testing practices suggest that we don't test abstract classes,
instead we focus our testing efforts upon the most derived classes - as
these are the ones who are going to be used and could well override
functionality defined in base classes.  Therefore we might just have two
testcase classes:

class FirstMostDerivedTests extends Testcase {}
class SecondMostDerivedTests extends Testcase {}

However, if during development of these tests, we find duplication, it
might be worthwhile in creating an abstract base class for the tests, so
that help methods could be defined and used by both. Likewise, it might
be appropriate for the abstract testclass to contain 'some' unittests
which are applicable to both classes under test.

e.g. the tests above become:

class AbstractTests extends Testcase{}

class FirstMostDerivedTests extends AbstractTests {}
class SecondMostDerivedTests extends AbstractTests {}

We might however decide that instead of using inheritance, regardless of
the fact that the class under test use inheritance, that we use
association instead.

Andrew

System.in is a stream. Refactor the classes to accept an input stream and
then pass in a memory stream.

  Amir Kolsky
XP& Software


>-----Original Message-----
>From: rubbinio [mailto:rubbinio@...]
>Sent: Saturday, April 09, 2005 5:02 AM
>To: junit@yahoogroups.com
>Subject: [junit] How to test this class ?
>
>
>
>
>I need to test a class in which all the methods read via System.in.
>
>How can I fake the input so that I can automate my tests ?
>
>Any answer will be helpfull ..... I am using JUnit under Eclipse.
>
>
>================================================================
>
>class Input {
>
>  static final BufferedReader keyboard = new BufferedReader(
>new InputStreamReader(System.in));
>
>  static int readInt()  throws IOException {
>   // I1
>    return new Integer (keyboard.readLine().trim() ).intValue() ;
>  }
>
>  static double readDouble()  throws IOException{
>   // I2
>    return new Double (keyboard.readLine().trim() ).doubleValue() ;
>  }
>
>  static double[] readDoubleLine()  throws IOException  {
>   // I3
>    StringTokenizer dline = new StringTokenizer (keyboard.readLine()) ;
>    double[] values = new double[dline.countTokens()] ;
>    for (int i = 0 ; i < values.length ; i++ ) // T4
>    {
>    	 // I5
>    	 values[i] = new Double
>(dline.nextToken()).doubleValue() ;
>    }
>      // I6
>    return values ;
>  }
>
>  static int[] readIntLine()  throws IOException  {
>   // I7
>    StringTokenizer iline = new StringTokenizer (keyboard.readLine()) ;
>    int[] values = new int[iline.countTokens()] ;
>    for (int i = 0 ; i < values.length ; i++ ) // I8
>    {
>    	 // I9
>         values[i] = Integer.parseInt (iline.nextToken()) ;
>    }
>    // I10
>    return values ;
>  }
>
>  static char[] readCharLine()  throws IOException {
>   // I11
>    String cline = keyboard.readLine() ;
>    char[] values = new char[cline.length()] ;
>    cline.getChars(0,cline.length(),values,0);
>    return values ;
>  }
>
>  static String readString() throws IOException {
>   // I12
>    return keyboard.readLine();
>  }
>
>}
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>

Rubbinio,


You can redirect System.in:


public class SystemInRedirecting extends TestCase{

	 public void test_allFeaturesInOneTestMethod() throws IOException
	 {
		 System.setIn (new StringBufferInputStream("test data\nline 2"));

		 assertEquals("test data", Input.keyboard.readLine () );
		 assertEquals("line 2"   , Input.keyboard.readLine () );

	 }
}


Problem: your 'Input.keyboard' is static, and final
    => you can redirect only once => all the tests must occur in the same
test method.
    => your test must redirect System.in before the very first call to
the Input class.


Alain

Hi.

When I run my tests using class reloading I get into a
java.lang.OutOfMemoryError.

My questions are:



1. What is the connection between using class reloading and memory
problems ?
2. What is the motivation behind ReloadingTestSuiteLoader and why
is it the default (the javadocs don't say much)?





10x for any lead.

.........................

Daniel Or

```````````````````````````





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

Hello,

I am on a project that is using jUnit to test j2ee components. I am
using a mock
HttpServletRequest to test a class that extends the
org.apache.commons...FileUploadBase
class. I have been getting boundary condition does not exist error.

I have two questions: 1) how do I set the boundary string for the
multipart file?
2) How do I ensure the file I upload used the same boundary
condition? Can I mock-up a
test file and attach it to my mock HttpServletRequest?

Hi!

One way to test if two objects have tha same data in a test is to use
the assertEquals(Object a, Object b) method and then implement
equals() and hashCode() in the tested classes. This seems like
simplest and most elegant solution to me.

The problem though is when a test fails, you don't get any
informartion about what field(s) that actually differed between the
two objects. You could also implement a toString() method, but for
large classes it's still quite hard see in the test output where the
mismatch is.

Because of this I usually write a series assertEquals(a.getFoo(),
b.getFoo()) statements in my test case instead, event though I would
prefer the equals() way of doing it.

Does anyone have a neat solution to using the equals() method in tests
and still get good output from the tests when something fails?

Regards, Mattias