https://github.com/heedrox/tcr-mars-rover
Mars Rover Kata implemented through TCR (test commit revert)
https://github.com/heedrox/tcr-mars-rover
Last synced: about 2 months ago
JSON representation
Mars Rover Kata implemented through TCR (test commit revert)
- Host: GitHub
- URL: https://github.com/heedrox/tcr-mars-rover
- Owner: heedrox
- Created: 2018-12-30T11:34:38.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2018-12-30T14:44:01.000Z (over 7 years ago)
- Last Synced: 2025-01-17T18:03:00.068Z (over 1 year ago)
- Language: JavaScript
- Size: 89.8 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# TCR Mars Rover
My first implementation of a kata through TCR.
Based on skeleton: https://github.com/jmarti-theinit/test-commit-revert-node
It uses Mocha + Chai + Sinon.
# About the Mars Rover Kata
http://kata-log.rocks/mars-rover-kata
Requirements
- You are given the initial starting point (x,y) of a rover and the direction (N,S,E,W) it is facing.
- The rover receives a character array of commands.
- Implement commands that move the rover forward/backward (f,b).
- Implement commands that turn the rover left/right (l,r).
- Implement wrapping from one edge of the grid to another. (planets are spheres after all)
- Implement obstacle detection before each move to a new square. If a given sequence of commands encounters an obstacle, the rover moves up to the last possible point, aborts the sequence and reports the obstacle.
# About TCR
TCR (test, commit || revert), is a new way of developing, with similar basics to TDD. But with added constraints.
TCR forces you to make baby steps, through one constraint: every time tests fail, you must revert your code.
Learn more about this here:
https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864
# About TCR-CLI
tcr-cli is the command line interface I developed that has all the test && (commit || revert) logic.
# This repo
This repo is an attempt to test if TCR can work in a real environment (at least in a Kata).
And to test also tcr-cli.
# Learnings and Reflections
- Generally forces you to create two tests (the dummy and the one that really validates)
- The commit history is based on test cases, and I think that's cool (the problem are refactors)
- I thought it was going to be a problem when saving multiple files, but it is not (because of watch delay)
- Tests passing are a free moment => refactors and everything are cool
- Synchronize all the time (mainly when refactor and fail) command + alt + Y
- Ejemplo isMovingCommand and isMoveCommand => he ido generando la otra, y cuando ya he visto que compilaba, la he swapeado.
- Veo menos el mensaje de error, ya que ya sé cuál es (excepto excepciones)
- console.log makes it appear in your log commit.
(For Mars Kata Reflections)
- I implemented the detection of obstacle signaling through Exception.
- I dont think obstacles should be injected, should they? whose responsability is the obstacle detection?