• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

outputStream doubt

 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i know this lies inside a JUnit test, but my problem is with i/o

i guess i'm quite close, because junit says:

my JUnit test:


inside junit i also have:


i also tried outputStream.toString() -> no way, and also outputStream.toString().trim() but this one enters an infinite loop
[ June 22, 2005: Message edited by: miguel lisboa ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I made a lot of changes here in hopes of pointing you in a better direction. It's important to design for testability: rather than having methods use a lot of hidden member variables and return their result via a side-effect, write them to take arguments and return a value. If they are called by other methods in the class, it's easy for those other methods to supply the members as arguments, right?

Remember to close any files you open, as I've done here.

Note that this test will pass under one circumstance only: that "a.txt" is an empty file. If it contains bad numbers, then there will be an ERROR for each bad number, plus one for the end of file. It's better to have a method like this throw an exception than return a flag value like -1 for end-of-file, but I'll leave that to you.

 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ernest, thank you for your answer

i did read it carefully; i rearranged my classses to acomodate your code, commented out any other tests, emptied a.txt and run, but got a:
java.lang.OutOfMemoryError: Java heap space

after, i tried with one line: 'x', but the same; tried with 'x' and '12':

junit.framework.ComparisonFailure: expected:<......> but was:<...



i've other Qs concerning your code, but i'll wait till this is cleared up

tx again
 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

pointing you in a better direction


allways wellcome!

It's important to design for testability


you might not believe it but i'm re writing my HiLo game trying to use tdd, but that's where i got blocked because of testing this method (yes, method must be re written)

rather than having methods use a lot of hidden member variables and return their result via a side-effect, write them to take arguments and return a value. If they are called by other methods in the class, it's easy for those other methods to supply the members as arguments, right?

who am i to disagree, but i thought that, partially i was doing it - see my HiLo constructor: had a reader and a writer as @params...
as to side effects, yes, its better to return;
anyway, i'd like my error message be printed with System.out.println - and here i've a Q: cant it be done? i mean, test System.out.println instead of write()?

TiA
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm, sorry. Turns out that parseInt() throws a NumberFormatException if the argument is null, indeed, you'll get an endless loop terminating with an OutOfMemoryError. You'd have to do something like

[code]
while (true) {
try {
String line = input.readLine();
if (line == null) {
writer.println("ERROR");
return -1;
} else
return Integer.parseInt(line);
} catch(NumberFormatException nfe) {
// Get here on non-numeric input
writer.println("ERROR");
}
}
 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i'll get to your last post next;

i was playing with code and, with a.txt with two lines ('z', '12') and with test was green

i must confess: I/O is quite a mystery to me ...
 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks again Ernest, your code is perfect.

forgive me for insist in asking you to teach me how to use System.out.println instead of write(). I heard about redirecting output, but as you might guess, all this is quite labyrinthic to me

TiA

EDIT:
i just found out that your code runs fine wih a.txt with 'x', '12' too

[ June 22, 2005: Message edited by: miguel lisboa ]
EDIT AGAIN

i just found out that my original code compiles, runs and tests ok if i use System.out.print instead of print...ln!!!
(that doesnt mean i'll not refactor it along with what you recomended)
thanks, Ernest
[ June 22, 2005: Message edited by: miguel lisboa ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic