wood burning stoves*
The moose likes Beginning Java and the fly likes Intro to JUnit Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Intro to JUnit Question" Watch "Intro to JUnit Question" New topic
Author

Intro to JUnit Question

Anthony Gilke
Greenhorn

Joined: Mar 01, 2012
Posts: 8
Trying to test a void method but I've never used JUnit and I'm having a hard time finding anything online that can help my situation.

Here is my class. I'm attempting to test the addItem method.

I'm not getting errors but it's not testing the two to see if they compare. I'm not even sure what to test to be honest. If I can get through one of these and understand it I believe I can do the 15 others that I have to do! Any help would be greatly appreciated. Thanks.




Here is my test area so far.... Pretty sure I have it wrong. It doesn't come up with any errors but doesn't seem to test correctly.



Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38020
    
  22
You would have to explain what the bit about asserting equals means. Does it mean you are asserting pepsi and pepsi are the same? Aren’t they both the same object? How could they ever be different?
William P O'Sullivan
Ranch Hand

Joined: Mar 28, 2012
Posts: 860

Anthony, Campbell is correct.

What you want to test for is that "pepsi" was in fact added to the vending machine.

Now how would you do that?

WP
Anthony Gilke
Greenhorn

Joined: Mar 01, 2012
Posts: 8
William P O'Sullivan wrote:Anthony, Campbell is correct.

What you want to test for is that "pepsi" was in fact added to the vending machine.

Now how would you do that?

WP


That sounds exactly like I want to do. I just put pepsi and pepsi in there so it wouldn't error out! I'm not sure how to do that. I think I understand what I need to do but just not sure how to do it.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38020
    
  22
There is something peculiar about four codes for the slots. Maybe you should create a VendingSlot class. You can have an array of slots as a field of your machine, or a List<VendingSlot>. You can easily search the List or array for an object which corresponds to “pepsi”.

Get a pencil and write down a description of a VendingSlot class, and its methods and fields.
Anthony Gilke
Greenhorn

Joined: Mar 01, 2012
Posts: 8
Campbell Ritchie wrote:There is something peculiar about four codes for the slots. Maybe you should create a VendingSlot class. You can have an array of slots as a field of your machine, or a List<VendingSlot>. You can easily search the List or array for an object which corresponds to “pepsi”.

Get a pencil and write down a description of a VendingSlot class, and its methods and fields.


That may be over my head! I guess if there is an issue with the four codes for the slots then it won't function. Ughhhhh!
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4445
    
    5

You can get to the issue with the slot codes later. I concur that given more modern language constructs, the design/implementation of the slots is, well, so 1995. But let's worry about that later.

If you're going to test addItem() then you need to understand what addItem is doing.

What should happen when the slot your trying to add the item to is already occupied? That's one test.
What should happen to the VendingMachine when the item is added successfully? That's another test.
What should happen when the parameter you pass in to addItem is not a valid slot code (like what your current test is doing)? That's actually another test.

And as far as I can tell, with these three tests, you should have full test coverage of the addItem() method. That is, these three tests combined exercise all possible execution paths through the addItem() method.

As for the JUnit test, referring to your listing:
1. Line 18: are you sure about the parameters you're passing? What's the second parameter supposed to be/represent?
2. Line 19: Prefixing "Assert." is fine but redundant. You have already done a static import on Line 3.
3. Line 19: assertEquals( message, expected, actual ) -- you pass in pepsi and pepsi, so naturally the assertion passes. But what are you testing? Which of the above three test cases are you trying to implement?

Some practices I have adopted for making tests more expressive:

- Method name : since this is not production code, test method names are exempted from following the normal Java naming convention for method names.
Prefer to make the names long and descriptive of exactly what the test is about and what you're expecting. This makes for more self-documenting test code.
- The Three As : Arrange, Act, Assert - a popular way to outline what you do in a test

BTW, in the above example, you should replace CONDITION and WHAT with something more appropriate. Left that for you to do so can still claim you did (most of) the work.

Junilu - [How to Ask Questions] [How to Answer Questions]
Anthony Gilke
Greenhorn

Joined: Mar 01, 2012
Posts: 8
Junilu Lacar wrote:You can get to the issue with the slot codes later. I concur that given more modern language constructs, the design/implementation of the slots is, well, so 1995. But let's worry about that later.

If you're going to test addItem() then you need to understand what addItem is doing.

What should happen when the slot your trying to add the item to is already occupied? That's one test.
What should happen to the VendingMachine when the item is added successfully? That's another test.
What should happen when the parameter you pass in to addItem is not a valid slot code (like what your current test is doing)? That's actually another test.

And as far as I can tell, with these three tests, you should have full test coverage of the addItem() method. That is, these three tests combined exercise all possible execution paths through the addItem() method.

As for the JUnit test, referring to your listing:
1. Line 18: are you sure about the parameters you're passing? What's the second parameter supposed to be/represent?
2. Line 19: Prefixing "Assert." is fine but redundant. You have already done a static import on Line 3.
3. Line 19: assertEquals( message, expected, actual ) -- you pass in pepsi and pepsi, so naturally the assertion passes. But what are you testing? Which of the above three test cases are you trying to implement?

Some practices I have adopted for making tests more expressive:

- Method name : since this is not production code, test method names are exempted from following the normal Java naming convention for method names.
Prefer to make the names long and descriptive of exactly what the test is about and what you're expecting. This makes for more self-documenting test code.
- The Three As : Arrange, Act, Assert - a popular way to outline what you do in a test

BTW, in the above example, you should replace CONDITION and WHAT with something more appropriate. Left that for you to do so can still claim you did (most of) the work.




This is great information. I really just want to test that I'm able to add an item.



I honestly have no idea what to put for item, code and expected and actual. I've stared at this for so long that I'm more confused than when I started!
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Anthony Gilke wrote:I honestly have no idea what to put for item, code and expected and actual. I've stared at this for so long that I'm more confused than when I started!

Almost every test case can be conceived like this:
1. There is an object with a state.
2. I do something with that object. Its state has changed.
3. I have an expectation of what the new state is. I examine the object to verify that my expectation coincides with reality.

You can think about it as if you are telling a story. Well-designed tests have a beginning, middle and end. Beginning: the state of things before we take any action. Middle: we perform the action we mean to test. End: what should have happened as the result of our action? Did it, in fact, occur?

There's a paradigm called behavior-driven development that attaches a helpful prefix to each part of the test.
For the beginning, we say "Given". This helps us focus our attention on the thing that is to be tested and avoid bringing in unnecessary stuff.
We might say "Given an empty VendingMachine." Be specific about the given state. It wouldn't be enough to simply say "Given a VendingMachine."

Our attention is now focused on the VendingMachine. For the middle, we use the word "When". This says something is going to happen.
"When an Item is added with code "D". Again, as specific as possible. If different behavior would occur depending on what the item is, then that should be specified.

Finally, we articulate the expected result of the action with "Then": "Then the supplied Item can be found in slot D".
Here we should look back at what was given: an empty vending machine. The assertion that concludes our test is concerned with the current state of that object.

Planning out your test cases like this makes writing the JUnit code a breeze. But even if you don't literally write this out, your thinking about the test should be structured this way.

Note that your original code merely compares a reference to itself. What we want instead is to examine the state of the VendingMachine by calling getItem and looking at what is returned.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Intro to JUnit Question
 
Similar Threads
Extending the VendingMachine
Illegal start?
"private" access
Why am I getting a Null Pointer Exception???
Rate my code