• 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

Intro to JUnit Question

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 859
IBM DB2 Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anthony Gilke
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic