Ive created the below method and now I have to use Junittesting. the below method is basically you can input number from 2 to 5. you cant input number below 2 or above 5. Im using eclipse to do Junit testing. how would I use the the below method for Junit testing?
Well, this is where some of the design lessons we've tried to teach you come home to roost. You really can't test this method sensibly; I guess I should say you could, but it'd be fairly involved, and more complex than the method itself. This is basically because the method does too many things, and doesn't do them in a modular way. So, for example, the method reads standard input and writes standard output, both; therefore, to test it, you'd have to mock up both of them, not impossible, but as I said, more complex than the method itself. It also uses member variables like globals, for no good reason, which again, makes things difficult to test, especially if the members are private, as all member variables should be.
And I'm really unhappy to see that you're still doing this thing where you throw an exception and then catch it in the same method -- it's truly heinous, and if this is for a grade, then the professor will not be impressed at all.
You need a method that takes a Reader and Writer as arguments, and returns an int, the number of players. Then you can pass in a StringReader and StringWriter as argument, and your test can check the StringWriter's contents to see the prompts that were printed, and the return value to check the result -- that would be an easy method to test. But this is designed to make testing extremely difficult -- I've told you that along the way, several times already.
I understand what your saying. i have to do them in stages I have to show them in stage 1 to 6. but for stage 1 we have to show with the methods we created How Junit is used. Im not sure what would I need to input Asserttrue? or just Assert? for testing each method by inputing the wrong numbers and the right ones.
//heres my early method how would you do Junit testing on it.
As Ernest, I wouldn't test it. It's too complicated - you had to mock System.in and System.out. If you are new to JUnit, which your question about asserts seems to suggest, this is just too much. It would also teach you the wrong lesson - the right lesson to learn is to write code that is easier to test.
Why are you insisting on testing the method as-is?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Well, as I'm saying, you'd need a tremendous amount of setup to test anything. You'd need to use a ByteArrayInputStream as a replacement object for System.in, and a ByteArrayOutputStream to make a PrintStream to use as System.out (see the setIn() and setOut() methods in the System class). Be sure to preserve the old values, and put them back afterwards! Populate the ByteArrayInputStream with the characters you'd like to pretend the user is typing, then create an object and call the method. Then you can assertEquals() on the contents of the ByteArrayOutputStream to see that what you think should have been printed, was indeed printed; and you can use assertEquals() to check that the value of the member noOfPlayers is what you think it should be.
But as given below, I'm not sure the method would even work; you assign a value to "noOfPlayers", but then test a different variable named "Players!" I also see an extra semicolon that will prevent it from working. I see some missing characters including a missing parenthesis that will prevent it from even compiling in the first place.
I'm no JUnit expert (I'm practicing though). But I've found that if you want to make a class *testable* the easiest way it to write the tests before you write the methods. I must confess that I'm still getting the hang of this. It also seems that when I do this I end up with a lot shorter more focused methods and classes.
[ November 05, 2006: Message edited by: Garrett Rowe ]
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter