https://github.com/albertllousas/point-of-sale-kata-definition
Kata definition to practice TDD, please clone it and enjoy!
https://github.com/albertllousas/point-of-sale-kata-definition
Last synced: about 2 months ago
JSON representation
Kata definition to practice TDD, please clone it and enjoy!
- Host: GitHub
- URL: https://github.com/albertllousas/point-of-sale-kata-definition
- Owner: albertllousas
- Created: 2022-07-19T16:04:55.000Z (almost 3 years ago)
- Default Branch: master
- Last Pushed: 2024-04-19T18:25:11.000Z (about 1 year ago)
- Last Synced: 2025-01-30T22:48:25.790Z (3 months ago)
- Language: Kotlin
- Size: 210 KB
- Stars: 0
- Watchers: 3
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
# Point of sale - kata definition
> TDD is important. TDD works. TDD is a professional discipline that all programmers should learn and practice. But it is not TDD that causes good or bad designs. You do that.
>
> Uncle Bob
## Description
Code kata to practice outside in tdd inspired by [super market kata](http://codekata.com/kata/kata09-back-to-the-checkout/) but
slightly different.
The idea is to code a **Point of Sale**, by which we could calculate and checkout an ongoing sale in a supermarket.
## Catalog
```
Product-id Price Description
--------------------------------
901234 1.50 Chips
507780 2.35 Red Bull
```
## ACs
- When a product is scanned, the price is **shown in the display**.
- When a scanned product is not present, a message 'invalid product' is displayed.
- Each time a product is scanned successfully, it will be added to the current digital shopping cart, keeping track of all the items for this sale.
- If a product was added by mistake, we can remove it from the current cart by product-id, the price will be displayed in negative.
- In any moment, we can cancel the current sale, clearing out the cart.
- When the sale is finished, the point of sale will check out, calculating the total price and displaying it.
## Rules
1. RED: Create a unit tests that fails.
1. Red means that the test fails, the assertion fails (You may have to write the minimal code to make the compiler happy)
2. GREEN: Write code that makes that test pass.
1. Make the tests pass by writing the minimal code necessary
3. REFACTOR: Clean up the mess you just made.
1. Write code that you are proud of
2. Refactor old and new code
## Hints
There are multiple ways to solve this exercise, as you can see there is no code to start with, try to solve in a scalable
, maintainable and decoupled way.
## Outside-in TDD
## Resources
- http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/
- https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
- https://martinfowler.com/bliki/TestDrivenDevelopment.html