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
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.
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.
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!
Don't get me started about those stupid light bulbs. |