Supply Chain Exercise

The Supply Chain directory is a truffle project that contains the required contract, migration and test files. In this exercise you are going to implement the SupplyChain.sol contract and write some tests in Solidity.

Instructions

Clone this repo to your local machine.

Follow the comments outlined in SupplyChain.sol (in the contracts directory) to implement its functions. We have written a set of tests (in javascript) to determine if your implementation is correct.

As an optional challenge, try writing some Solidity tests in TestSupplyChain.sol. This is not required, however!

To test your implementation run $ truffle test from the terminal in the project directory. There are 23 pending tests that you must pass to complete this exercise.

Similar to the Simple Bank Exercise, check out the test file to see the tests that define the behavior of the SupplyChain smart contract.

State variables

• should have an owner

  📖

  The contract should have an owner, of type address that is public. hint: define a public variable owner of type address

• should have an skuCount

  📖

  The contract will keep track of the skus in our supply chain. Each item for sale will have a unique sku number.

  hint: define a public variable called skuCounter of type uint

enum State

Items can exist in our Supply chain domain in a few states. In Solidity an enum can be used to represent these different states. Remove the skip annotation from the enum tests to proceed.

• should define ForSale for when an item is put on sale
• should define Sold for when an item has been purchased
• should define Shipped for when an item has been shippd to the buyer
• should define Received for when the shipped item has been received by the buyer

Item struct

How do we describe an item in our supply chain? It is a union of properties: name, sku, price, state, seller and buyer. We can use a Solidity struct to model this Item. Remove the skip annotation from the Item struct tests and proceed.

• should have a name
• should have a sku
• should have a price
• should have a state
• should have a seller
• should have a buyer

SupplyChain Use cases

NOTE Before proceeding, you should un-comment the fetchItem function in the contract. This function is necessary to validate the remaining tests.

• should add an item with the provided name and price
  📖

  use case: As a seller, I want to add an item for sale. I should
• should emit a LogForSale event when an item is added
  📖

  use case: Whenever an item is added (placed for sale), the contract should emit a `LogForSale` event
• should allow someone to purchase an item and update state accordingly
  📖

  use case: As a buyer, I want to purchase an item that is for sale.
• should error when not enough value is sent when purchasing an item
  📖

  use case: A buyer will be notified when they do not have enough funds for the purchase
• should emit LogSold event when and item is purchased
  📖

  use case: Whenever an item is bought (sold), the contract should emit a "LogSold" event
• should revert when someone that is not the seller tries to call shipItem()
  📖

  use case: As a seller, only I can ship a bought item
• should allow the seller to mark the item as shipped
  📖

  use case : Whenever an item is shipped, the seller should be able to mark the item as shipped
• should emit a LogShipped event when an item is shipped
  📖

  use case: Whenever the item is shipped, the contract should emit a "LogShipped" event
• should allow the buyer to mark the item as received
  📖

  use case: Whenever an item is recieved, the buyer should be able to mark the item as received
• should revert if an address other than the buyer calls receiveItem()
  📖

  use case: As a buyer, only I can mark the item as received
• should emit a LogReceived event when an item is received
  📖

  use case: Whenever an item is received, the contract should emit a "LogReceived" event