implement vending application

[s ravi chandran]

Hi,
I am working on improving my coding skills. I know the basics in theory, but my overall application ends up in a mess most of the time, in terms of understanding for other developers. So, I am working on a problem and hopefully will learn to write better organized code while improving on this application.

I found a problem on a site which is like this:

Design vending machine in Java which vends Item based upon four denomination of coins and return coin if there is no Item.

i have created these classes to solve it. There is no design pattern used. It is not optimized. It doesn't support multi threaded requests.

public enum CurrencyDenomination 
{
	NICKEL,
	PENNY,
	DIME,
	QUARTER
}

public enum VendingProduct 
{

	FRUIT_JUICE(CurrencyDenomination.PENNY),
	MILK(CurrencyDenomination.DIME),
	COOKIES(CurrencyDenomination.NICKEL),
	CHOCOLATE(CurrencyDenomination.DIME),
	COLD_DRINK(CurrencyDenomination.QUARTER);

	private CurrencyDenomination itemCost;

	private VendingProduct(CurrencyDenomination price)
	{
		itemCost = price;
	}

	public CurrencyDenomination getPrice()
	{
		return itemCost;
	}

	public String toString()
	{
		return this.name()+"["+itemCost+"]";
	}
}

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

public class VendingMachine {

	List< VendingProduct> itemList ;
	public static final int EACH_ITEM_MAX_QUANTITY= 5;

	VendingMachine()
	{
		itemList = new ArrayList<VendingProduct>();
	}

	public void populateVendingMachine()
	{
		Random random = new Random();

		int randomItemCount = random.nextInt(EACH_ITEM_MAX_QUANTITY) + 1;

		// fruit juices
		for(int i = 0; i< randomItemCount; i++)
		{
			itemList.add(VendingProduct.FRUIT_JUICE);
		}

		randomItemCount = random.nextInt(EACH_ITEM_MAX_QUANTITY) + 1;

		// chocolate
		for(int i = 0; i< randomItemCount; i++)
		{
			itemList.add(VendingProduct.CHOCOLATE);
		}

		randomItemCount = random.nextInt(EACH_ITEM_MAX_QUANTITY) + 1;
		// cold drink
		for(int i = 0; i< randomItemCount; i++)
		{
			itemList.add(VendingProduct.COLD_DRINK);
		}

		randomItemCount = random.nextInt(EACH_ITEM_MAX_QUANTITY) + 1;
		// milk
		for(int i = 0; i< randomItemCount; i++)
		{
			itemList.add(VendingProduct.MILK);
		}

		randomItemCount = random.nextInt(EACH_ITEM_MAX_QUANTITY) + 1;
		// cookies
		for(int i = 0; i< randomItemCount; i++)
		{
			itemList.add(VendingProduct.COOKIES);
		}

	}

	public List<VendingProduct> getItemList()
	{
		return itemList;
	}

	public boolean purchaseItem( VendingProduct itemToBuy, CurrencyDenomination price)
	{
		if(itemList.contains(itemToBuy) && itemToBuy.getPrice() == price)
		{
			System.out.println("Item "+ itemToBuy+" available.");
			System.out.println("Item bought for a "+price);
			System.out.println();
			itemList.remove(itemToBuy);
			return true;
		}
		else if(itemList.contains(itemToBuy) && itemToBuy.getPrice() != price)
		{
			System.out.println("Item "+ itemToBuy+" available.");
			System.out.println("Item cannot be bought for "+price);
			System.out.println();
			return false;
		}
		else
		{
			System.out.println("Item "+itemToBuy+" not available.");
			System.out.println("Returning amount "+price);
			System.out.println();
			return false;
		}
	}
}

import static org.junit.Assert.*;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

public class VendingMachineTest {

	private static VendingMachine vendingMachine;

	@BeforeClass
	public static void setUp(  )  {
		vendingMachine = new VendingMachine();
		vendingMachine.populateVendingMachine();

		System.out.println("Available items");
		System.out.println(vendingMachine.getItemList());
		System.out.println();
	}

	@Test
	public void getItemList()
	{
		assertNotNull(vendingMachine.getItemList());
	}

	@Test
	public void populateVendingMachine()
	{
		assertTrue(vendingMachine.getItemList().size() > 0);
	}

	@Test
	public void successfullPurchaseOfItem()
	{
		assertTrue(   vendingMachine.purchaseItem(VendingProduct.CHOCOLATE, CurrencyDenomination.DIME)	    );
		assertTrue(   vendingMachine.purchaseItem(VendingProduct.FRUIT_JUICE, CurrencyDenomination.PENNY)	);
		assertTrue(   vendingMachine.purchaseItem(VendingProduct.COOKIES, CurrencyDenomination.NICKEL)	    );
		assertTrue(   vendingMachine.purchaseItem(VendingProduct.COLD_DRINK, CurrencyDenomination.QUARTER)	);
	}
	
	@Test
	public void unsuccessfullPurchaseOfItemDueToCost()
	{
		assertEquals( vendingMachine.purchaseItem(VendingProduct.CHOCOLATE, CurrencyDenomination.DIME) , false   );
	}
	
	@AfterClass
	public static void tearDown(  )  {
		System.out.println("*** Purchase Complete ***");
	}

}

I wish to know how I can solve it in a better manner.

Thanks
Ravi

[Ulf Dittmer]

"Better" in what sense?

It is not optimized.

Optimize for what? Why do you think it needs to be optimized?

It doesn't support multi threaded requests.

How do you wish to support concurrency? There are any number of ways to do that. In which way do you think your current approach does not?

[s ravi chandran]

Ulf Dittmer wrote:"Better" in what sense?

It is not optimized.

Optimize for what? Why do you think it needs to be optimized?

It doesn't support multi threaded requests.

How do you wish to support concurrency? There are any number of ways to do that. In which way do you think your current approach does not?

Okay, just starting with the basic requirement of making it more modular, organized and efficient. Then I would work on adding multiple request support, like having many threads requesting for items simultaneously.
Right now I am using very few items. i can expand it to have a bunch of vending machines with each having a different set of items. each will be requested for an item for a user and rest of the process will remain the same.

[Junilu Lacar]

First, the positives:
1. You accept that you have much to learn.
2. You are trying to write unit tests
3. You came to the Ranch to get help and advice.

The basic problem here is that of design. Let's question a few of the choices you made or are considering:

1. Why are you defining VendingProduct as an enum?
2. What aspect of your design and API are you really testing with your unit test? Does each test document a specific aspect of the design and API?
3. Why do you think a vending machine should support multithreading?

Things to ponder:
1. enums are meant to represent things that don't change or change very rarely. Does your set of products fit this description?
2. What's going to happen when your product prices change?
3. Your unit tests should be examples of how you would use the class under test. Specifically, they should be detailed documentation of different aspects of the API design. Also, unit tests should be FIRST
4. Think about a real-life vending machine. Have you ever seen one that lets more than one person buy things at the same time? One person putting enough money in to buy multiple items is plausible but I've never seen a vending machine that let two or more people buy things at the same time.
5. A vending machine can be viewed as a state machine. Some states are: READY, OFFLINE, EMPTY, VENDING, WAITING, RETURNING_CHANGE. What input would you need to go from one state to another? What functions of the vending machine are available at each state? What API calls would you make to move from one state to another? How would your program control the physical parts of the vending machine? What API calls would you make to do that?

[Junilu Lacar]

s ravi chandran wrote:i can expand it to have a bunch of vending machines with each having a different set of items. each will be requested for an item for a user

How do you propose to do that with your current design with VendingProduct as an enum? Add more enums? Is that a good design choice?

Think about this: In real life, how are vending machines set up? What does the guy who fills the vending machine have to do when he fills up the machine? What kind of user interface does the guy have so he can program the machine to know things it needs to know to sell products properly. How does the machine know when there are things to sell and when a slot is empty? How does the machine know how much to charge for each item? How does it know if enough money was dropped in? How does it know when it needs to give back change?

[s ravi chandran]

Junilu Lacar wrote:

s ravi chandran wrote:i can expand it to have a bunch of vending machines with each having a different set of items. each will be requested for an item for a user

How do you propose to do that with your current design with VendingProduct as an enum? Add more enums? Is that a good design choice?

Think about this: In real life, how are vending machines set up? What does the guy who fills the vending machine have to do when he fills up the machine? What kind of user interface does the guy have so he can program the machine to know things it needs to know to sell products properly. How does the machine know when there are things to sell and when a slot is empty? How does the machine know how much to charge for each item? How does it know if enough money was dropped in? How does it know when it needs to give back change?

Okay, well, I initially used enum to define items listed on the machine. As they won't change much over time, unless I am adding a new set of item range. currency i changed later on to enums as a starting point to have a limited set of currency values to begin with, which could be changed to a class implementation when design for other functionality were clear to me.

this is the first time I have written a unit test case actually. I know its kind of a late start.. But I am more focussed on getting started with overall project development. This is also one aspect I wish to improve upon as I understand the testability of the vending machine. For now the vending machine is top level abstraction, I am not adding any advanced level functionality to it. I need to first make a good design for the current abstraction level. I can then improve over that design.

Multi threading aspect is only being added for learning purpose, I will not be emulating everything as per real life scenario. That I should be able to do once I know how to understand the requirement for a project and think of possible design aspect for them, from my experience gained from such exercises as the current one.

your suggestions are appreciated. I need to add more components to the design. Will work on both design and analysis for this.

Thanks
Ravi

[Junilu Lacar]

s ravi chandran wrote:Multi threading aspect is only being added for learning purpose, I will not be emulating everything as per real life scenario.

Part of learning how to design properly is learning how to apply the proper solution to the given context. Perhaps more importantly, you should know when NOT to apply a certain technique. Would you attempt to learn how to swim in a pit of mud? Or learn to ride a bicycle in a swimming pool? By the same token, if you're going to learn about concurrency, then you should choose a problem where concurrency is applicable. This vending machine problem is not a good candidate for that, IMO.

[Junilu Lacar]

s ravi chandran wrote:I need to add more components to the design.

Before you do that, I think you should think about what functionality you want from your program. Here are some suggestions:

1. As a customer, I want to know what items are available
2. As a vendor, I want to add new items to sell
3. As a customer, I want correct change to be given back to me
4. As a vendor, I want to know how many items of each product were sold
5. As a customer, I want an easy and intuitive way to pick what I want to buy
6. As a vendor, I want the machine to dispense a product only if enough money has been deposited
7. As a customer, I want the machine to tell me if it does not have enough change to give back for the money I deposited.
8. As a customer, I want to cancel my transaction and get back all the money I deposited.

[Junilu Lacar]

s ravi chandran wrote:Okay, well, I initially used enum to define items listed on the machine. As they won't change much over time, unless I am adding a new set of item range.

I don't think this is a good design choice. Can you think of some other way to represent your collection of products?

Think about how actual vending machines are set up. Most of them have slots, with each slot having one type of product. This makes it easier for customers to choose the type of product they want to buy. It also makes it easy for the vendor to configure the machine to know how much to charge for the chosen product. Just assign the price to each slot, then when the customer selects that slot, charge that amount. Each slot will have a certain number of products it can hold. From time to time, the vendor will want to change the product being sold in a given slot. The same product can be sold from multiple slots.

Given all these considerations, you should be able to come up with some kind of data structure to represent the collection of products in your vending machine. An enumerated type is not appropriate for this.

[Junilu Lacar]

Why does your product price have a type of CurrencyDenomination? What if you had a product that you wanted to sell for $1.00? $1.25? $1.95? And how do you intend to calculate how much change you're going to give back to the customer?

[s ravi chandran]

Junilu Lacar wrote:Why does your product price have a type of CurrencyDenomination? What if you had a product that you wanted to sell for $1.00? $1.25? $1.95? And how do you intend to calculate how much change you're going to give back to the customer?

Okay, I have noted the points you gave. Will work on identifying the key components. about the currency denomination, well, as I said, i was trying to limit the functionality to first design a base level work flow. let me first try to get the design components first. I think it would be better to start from components to design level and then implementation.

Thanks
Ravi

[s ravi chandran]

Okay, I have so far identified these components

Vending Machine
Item Slot
Item
Machine Cash Management
Item Selector
Customer

Vending Machine will have a fixed set of Item Slots. Each item slot will have a fix number for items and also the pricing for the slot. Cash management will handle all the transaction processing. Item selector will pick the item from the slot and process will go to cash management for further processing. customer will initiate the purchase by giving certain amount and slot number to pick.


Did I miss some relevant sequence?

Thanks
Ravi

[s ravi chandran]

Added these classes from the identified components:

public class Item {

	private String itemName;
	private int itemPrice;

	public String getItemName() 
	{
		return itemName;
	}

	public void setItemName(String itemName) 
	{
		this.itemName = itemName;
	}

	public int getItemPrice() 
	{
		return itemPrice;
	}

	public void setItemPrice(int itemPrice) 
	{
		this.itemPrice = itemPrice;
	}
}

public class ItemSlot {

	private List<Item> itemList;
	private int slotPrice;
	private int slotNumber;
	private static final int MAX_ITEM_PER_SLOT = 6;

	public ItemSlot()
	{
		itemList = new ArrayList<Item>(MAX_ITEM_PER_SLOT);
	}

	public List<Item> getItemList() 
	{
		return itemList;
	}

	public void setItemList(List<Item> itemList)
	{
		this.itemList = itemList;
	}

	public int getSlotPrice() 
	{
		return slotPrice;
	}

	public void setSlotPrice(int slotPrice)
	{
		this.slotPrice = slotPrice;
	}

	public int getSlotNumber() 
	{
		return slotNumber;
	}

	public void setSlotNumber(int slotNumber)
	{
		this.slotNumber = slotNumber;
	}

	public void addItem( Item newItem)
	{
		if(this.itemList.size() < MAX_ITEM_PER_SLOT)
		{
			this.itemList.add(newItem);
		}
		else
		{
			System.out.println("Slot is full, not items can be added.");
		}
	}

	public void removeItem(int index)
	{
		if(! this.itemList.isEmpty())
		{
			this.itemList.remove(index);
		}
	}

	public String toString()
	{
		// show items available in the slot. 
		return this.itemList.toString();
	}

}

// this class is not complete yet. 

public class VendingMachine {

	private ItemSlot[] slots;
	private static final int MAX_SLOT_PER_MACHINE = 4;

	public VendingMachine()
	{
		slots = new ItemSlot[ MAX_SLOT_PER_MACHINE];
	}

	public ItemSlot getSlot(int slotIndex) 
	{
		return slots[slotIndex];
	}

	public void addSlots(ItemSlot slot) 
	{

		for (int i = 0; i < slots.length; i++) 
		{
			if (slots[i] == null) 
			{
				slots[i] = slot;
				break;
			}
		}
	}

	public void displayItems()
	{
		System.out.println( "*** Items Available *** ");

		for(int i = 0; i < slots.length; i++) {

			System.out.println("Slot Number "+i);
			System.out.println();
		}
	}
}

Does this look reasonable?

[Carey Brown]

ItemSlot.removeItem() should probably return a boolean to indicate if there was an item to remove.

[s ravi chandran]

Carey Brown wrote:ItemSlot.removeItem() should probably return a boolean to indicate if there was an item to remove.

added the changes.

public boolean addItem( Item newItem)
	{
		if(this.itemList.size() < MAX_ITEM_PER_SLOT)
		{
			this.itemList.add(newItem);
			return true;
		}
		else
		{
			System.out.println("Slot is full, not items can be added.");
		}
		
		return false;
	}

	public boolean removeItem(int index)
	{
		if(! this.itemList.isEmpty())
		{
			this.itemList.remove(index);
			return true;
		}
		
		return false;
	}

[Junilu Lacar]

I don't see a need to represent Customer in your program. A customer is an external entity and no information about a customer is needed for the machine to function. I'm not so sure about Item Selector. If it were me, I would have to write some test code to see what the code wants to do.

Where did your unit tests go? Right now, you are just adding code that you think you'll need rather than code that the tests tell you is needed. I find that Test-Driven Development and using tests to drive your design thinking results in better and more concise designs.

[s ravi chandran]

Junilu Lacar wrote:I don't see a need to represent Customer in your program. A customer is an external entity and no information about a customer is needed for the machine to function. I'm not so sure about Item Selector. If it were me, I would have to write some test code to see what the code wants to do.

Where did your unit tests go? Right now, you are just adding code that you think you'll need rather than code that the tests tell you is needed. I find that Test-Driven Development and using tests to drive your design thinking results in better and more concise designs.

Well, i thought the customer should initiate the process, hence thought to add that as a component. ItemSelector can be something which will do the purchase process like getting slot number, getting the item, checking the price and sending the process flow to cash management to calculate the return amount in case applicable.

here i have not added the test cases.. i was formalizing the design components. I wish to follow TDD pattern, but as I am learning both about project design and unit testing I would like to skip it for now. the objective is to understand the process and apply that to future requirements. that way I should be able to make better design decisions when using TDD in future.

Other than customer and item selector, is there any component missing or extra that you see? In a way item selector component functionality can be included in the vending machine component also. I can do that if that optimized the solution.

[Junilu Lacar]

The customer is an external actor who does not need to be included in your program model. If you were modeling a car, you don't need to include the driver because he too is an external actor. Learn to recognize where the boundary of your model lies otherwise you will include entities that are not actually part of the system just as you have with customer.

TDD is NOT a pattern. In fact, it is a design and development practice that focuses on writing tests for your design's API. IMO, if more people would just spend more time learning how to do it properly then there would be that many more people who learned how to combine test thinking with design thinking to produce better programs. I have been down the road you're on and I can tell you from experience that I wish I had known about TDD long before I had to unlearn a lot of bad habits I developed without it.

There are people who create good designs without doing TDD but they have a lot of experience and instinctively do things that TDD would have led them to do anyway. People like this are rare though. Regular people, like myself, have to just muddle through or rely on techniques like TDD to stay on the right track.

[Junilu Lacar]

Would it help if I showed you how this would be done with TDD?

[Junilu Lacar]

s ravi chandran wrote:my overall application ends up in a mess most of the time, in terms of understanding for other developers.

This is definitely something that TDD can address. Many people see "Test-Driven" and assume that TDD is about testing but it's actually much more than that. Tests are merely a means by which a good design can be made to emerge from the stories that you have about the system's desired behavior. A very important part of TDD is the practice of refactoring and that's what helps keep you from making a mess that other developers find difficult to work with.

[s ravi chandran]

I actually saw the basic theory about TDD, i understood what the process is like. Well, like i said in order to understand how TDD is helping in design, i should know what a good design is. Would you give an example for TDD if possible, i will try my best to understand the logic behind it.
I too have had my own share of bad design experiences, the main reason i wish to work on that part.

[Junilu Lacar]

s ravi chandran wrote:Well, like i said in order to understand how TDD is helping in design, i should know what a good design is. Would you give an example for TDD if possible

Sure. In the meantime, I'll move this thread to a more appropriate forum.

[Junilu Lacar]

The first thing to do is get a list of stories that describe the functionality to be provided by the program. I'll start with the ones I suggested earlier:

1. As a customer, I want to know what items are available
2. As a vendor, I want to add new items to sell
3. As a customer, I want correct change to be given back to me
4. As a vendor, I want to know how many items of each product were sold
5. As a customer, I want an easy and intuitive way to pick what I want to buy
6. As a vendor, I want the machine to dispense a product only if enough money has been deposited
7. As a customer, I want the machine to tell me if it does not have enough change to give back for the money I deposited.
8. As a customer, I want to cancel my transaction and get back all the money I deposited.

[Junilu Lacar]

Going through the stories, I'd decide to start with one that I think will be architecturally significant. I think I'll start with story #2: As a vendor, I would like to add new items to sell.

I would then start coding by writing a little bit of test code:

package com.coderanch.samples.design.vend;

import static org.junit.Assert.*;

import org.junit.Test;

public class VendingMachineTest {

	@Test
	public void should_be_able_to_add_products_to_sell() {
		VendingMachine testSubject = new VendingMachine();
	}
}

This code will fail to compile because there is no VendingMachine class.

I use Eclipse, so I tell Eclipse to fix that and it generates this code:

package com.coderanch.samples.design.vend;

public class VendingMachine {

}

Notice how I start with test code first, then when it tells me, via a compile-time error, that I need some production code, I go ahead and write production code. This is at the heart of the TDD technique: waiting for a failing test before writing any production code. For me, this is not a strict rule so much as it is something that you want to do as much as possible.

I'll continue with this later today when I have some time. Right now I have to get back to my day job.

[Junilu Lacar]

In the meantime, you can go through this thread to get a feel for what TDD would be like: https://coderanch.com/t/641831/Testing/book-Practical-Unit-Testing-JUnit#2950886

[Junilu Lacar]

So now that I have some production code for a vending machine, I want to think about what the API would be to add new products. To spur some ideas about the API design, I write a line of test code:

   @Test  
    public void should_be_able_to_add_products_to_sell() {  
        VendingMachine testSubject = new VendingMachine();
        testSubject.add("Slot 1", "M&Ms", 5);
    }

My thinking here is that to add some products to the vending machine, I will need to pass in a slot name, product name, and the quantity of product to add. This is just a "straw man" to spur discussion with the rest of the team or if you're doing this alone, with yourself. I usually code with at least one partner and have lately been advocating for mob programming. The best way to write code that other programmers can understand is to involve other programmers in writing and designing your program. The discussions that you have while programming as a pair or group are a source of invaluable feedback that you get immediately rather than later as often happens when you follow more traditional methods of solo programming.

If you were programming this with me and you saw me write that one additional line of test code, what kind of questions would you ask? What kind of discussion would ensue?

You should realize that TDD and software development in general is best done is small steps/increments and with a lot of thought and consideration put into making each increment. The tests help you keep everything working and ensure that any change you make doesn't break anything that already worked before. Writing tens or hundreds of lines of code before testing what you've written more often than not turns out to be wasteful in the long run. It's better to write a little bit of test code, then a little bit of code, then a little more test code, and so on. All this time, you are looking for opportunities to refactor and make the code clearer and better organized. As Robert "Uncle Bob" Martin likes to put it: "The only way to go fast, is to go well."

[Junilu Lacar]

Continuing... when I add the line of test code, I get a compiler error because VendingMachine does not have an add method. Again, I ask Eclipse to fix that and it generates this method for me in VendingMachine.java:

	public void add(String string, String string2, int i) {
		// TODO Auto-generated method stub
	}

And that's all I have to do to fix the compiler error. That's GREEN in the TDD cycle.

Now go to the REFACTOR step. Looking at the generated method, I see that the parameter names are not very descriptive. I change them to reveal the code's intent. I also remove the auto-generated TODO comment

	public void add(String slot, String productName, int quantity) {
	}

With this, I improved the clarity of code 100% (IMO). Then I go back to my test and add another line of test code, this time an assertion:

@Test    
public void should_be_able_to_add_products_to_sell() {    
    VendingMachine testSubject = new VendingMachine();  
    testSubject.add("Slot 1", "M&Ms", 5);  
    assertThat(testSubject.itemCount("Slot 1"), is(5));
}

Again, I get a compile error telling me that the method itemCount() on VendingMachine does not exist and again I ask Eclipse to fix that. The auto-generated method is not quite what I want it to be so I fix it:

	public int itemCount(String slot) {
		return 0;
	}

Notice that I haven't filled in the methods with any code yet except for a return value where one is needed to avoid getting a compiler error. I just return 0 for now. I know this is not the right code but I need to see a test fail before I can fix it.

TDD requires a lot of discipline to follow and it takes a while to get used to not caring about writing code that you know is wrong. You just have to realize that the only way you are allowed to fix it is when you see a failing test that can be made to pass by the fix. Here's the next thing that you might find crazy. To fix the assertion error, I do something that's obviously wrong but is enough to make the test pass.

	public int itemCount(String slot) {
		return 5;
	}

This makes my test pass. Why would I do this? Because I need to write another test that will show me that this, while it makes the current tests pass, will fail a different test. I need to write that other test that will show me that I still have a bug in the code, even though I know there obviously is a bug. In TDD, failing tests are what motivates you to fix code, not your intuition or knowing-for-a-fact-that-it's-wrong.

[Junilu Lacar]

I'm going to pause with the TDD example to give you a chance to ask questions and share some of your thoughts about where the design is going at this point. What do you think about the proposed API for adding products to sell from the vending machine? What do you think is the next test to write to show that the current implementation of the itemCount method has a bug?

[s ravi chandran]

Junilu Lacar wrote:I'm going to pause with the TDD example to give you a chance to ask questions and share some of your thoughts about where the design is going at this point. What do you think about the proposed API for adding products to sell from the vending machine? What do you think is the next test to write to show that the current implementation of the itemCount method has a bug?

Ok, I followed it till the last step. What I feel about TDD is that its all about intuitive programming. You take one business aspect of your application and start with calling that functionality. Based on what all you are missing, you fill the blanks with minimum code to make it run without error. Mostly that should happen even without the addition of business logic itself.

How do we identify the key business requirements to implement first? We have picked requirement no 2 from the list :

2. As a vendor, I want to add new items to sell

. Now following the finding the bug sequence. I think itemCount should be backed by a list of items.

Here we are just following from the requirement we started right? We will go through the code flow till we implement the requirements one by one.. That way, we should be following the requirements based on the dependencies when it arrives.

[s ravi chandran]

Now following the finding the bug sequence. I think itemCount should be backed by a list of items. . It should actually be a map of slot name and slot object which should take slot name, product name and quantity. Also, before this we should refractor the itemCount method

           public int itemCount(String slotName) 
          {		
               // slot object
		//Object selectedSlot = itemMap.get(slotName); 
                Object selectedSlot = new Object();
		//return selectedSlot.getQuantity();
               return 5;
	}

Does this look correct? I was actually thinking of a implementation for the slot objects, but i remembered TDD works with small steps at a time. So, just added these lines for now.

[Junilu Lacar]

That's an interesting point. There is a bit of intuition involved and I suppose you can't totally eliminate the need to rely on it. Choosing story #2 was based on my intuition that it would lead us to thinking about internal structures that would be needed to support the implementation of other functions. However, #2 is also something that has to happen before other interesting things can happen so it seems logical to start here.

As for your thinking that itemCount should be backed by a list, I think it's natural to think that but you have to resist that temptation until the code practically screams at you that a list is needed. Right now, that need is just a whisper. You need failing tests to amplify it. We'll see if we really need a list later when we have those.

Now, answer the question: What test can we write to reveal the bug in itemCount?

[Junilu Lacar]

s ravi chandran wrote: Does this look correct? I was actually thinking of a implementation for the slot objects, but i remembered TDD works with small steps at a time. So, just added these lines for now.

No, it doesn't. In fact, I would have you delete what you added because frankly you just made a big mess. This goes to show how little code you have to write to make a mess. You can't write production code until you have a failing test. Write some test code that will fail first.

[s ravi chandran]

Not sure. Maybe we could write a test to remove a product. The itemCount which is still static would the be giving wrong value.

[s ravi chandran]

Not able to pinpoint at a particular scenario. itemCount is directly related to product slots. So, any process that we do on slots should impact item count. purchase of a product will effect it.. right now all slots are having constant item count.

 testSubject.buy("Slot 1", "M&Ms", 1);

something like this?

[Junilu Lacar]

Don't write tests just because you can. Use tests to flesh out your design. We aren't even done with the functionality to add products yet so it's not the right time to move to removing products. The new test should help triangulate the correct implementation of adding products. You have a passing test that adds a specific amount right now and the implementation bug is that it only works for that particular case. We need to introduce another case for adding products where the implementation will obviously fail to produce the correct results.

[s ravi chandran]

Junilu Lacar wrote:Don't write tests just because you can. Use tests to flesh out your design. We aren't even done with the functionality to add products yet so it's not the right time to move to removing products. The new test should help triangulate the correct implementation of adding products. You have a passing test that adds a specific amount right now and the implementation bug is that it only works for that particular case. We need to introduce another case for adding products where the implementation will obviously fail to produce the correct results.

updated the add product.

@Test
	public void should_be_able_to_add_products_to_sell() {  
        VendingMachine testSubject = new VendingMachine();  
        testSubject.add("Slot 1", "M&Ms", 5);
        assertThat(testSubject.itemCount("Slot 1"), is(5)); 
        testSubject.add("Slot 2", "P&G", 4);
        assertThat(testSubject.itemCount("Slot 2"), is(4));
    }

[Junilu Lacar]

Here's another point to ponder: is itemCount even appropriate to introduce at this time? Is there something simpler that we can do to verify the add method? This question goes back to design focus. Try not to work on too many aspects of the design at once. The fewer unpolished facets of the design you have to deal with at one time, the simpler it is to make decisions and manage complexity.

[s ravi chandran]

Junilu Lacar wrote:Here's another point to ponder: is itemCount even appropriate to introduce at this time? Is there something simpler that we can do to verify the add method? This question goes back to design focus. Try not to work on too many aspects of the design at once. The fewer unpolished facets of the design you have to deal with at one time, the simpler it is to make decisions and mange complexity.

We can have add return true as a response for a successful add and false for a failure in add product. that way, we will only deal with add and not the products.

 public boolean add(String slot, String productName, int quantity)
	{
		return true;
	}

[Junilu Lacar]

The additional test you added is a step in the right direction. That's good. I will continue tomorrow when I get a chance. For now I want to draw your attention to how much discussion we've had so far and yet we only have relatively little code. This is the exact opposite of what happens when you do traditional solo programming: You write a lot of code with very little discussion with you co-developers. These discussions are where the real value of TDD lies in my book. The conversations are what helps create a common understanding of the code and design. A common understanding is always at the core of well written software.

[Junilu Lacar]

s ravi chandran wrote:
We can have add return true as a response for a successful add and false for a failure in add product. that way, we will only deal with add and not the products.

Ok, we can explore that option. At this point, I would commit whatever changes I've made so far into source control, like Git or SVN. Then we can either switch off the keyboard so you can drive or I can keep driving and you can navigate me through the changes. What test do you want to write for this API change? Obviously, our current test will have to be deleted or changed.