1
0
Fork 0
Go to file
Xavier Fontanet 42f1f19926 Merge remote-tracking branch 'origin/master' 2024-06-29 21:38:39 +02:00
mars-station a bit of Interface Segregation Principle 2024-06-26 00:54:16 +02:00
misc/images images fix 2024-06-24 17:21:37 +02:00
rover-api a bit of Interface Segregation Principle 2024-06-26 00:54:16 +02:00
rover-commands a bit of Interface Segregation Principle 2024-06-26 00:54:16 +02:00
tests-suite hierarchical tests 2024-06-29 21:38:30 +02:00
user-interface-console apply JPMS to user interface module and improve some namings 2024-06-24 16:28:54 +02:00
.gitignore minimal needed .gitignore 2024-06-20 14:30:58 +02:00
README.md kata description 2024-06-26 14:38:17 +02:00
SOLUTION.md images fix 2024-06-24 17:21:37 +02:00
pom.xml apply JPMS to user interface module and improve some namings 2024-06-24 16:28:54 +02:00

README.md

Mars Rover Backend Kata

Welcome. This kata consist in a solution that translates commands sent from Earth to instructions that are understood by a Rover on Mars

Functional requirements

Given:
 - a two dimensional map of Mars
 - the initial starting point and direction of the Rover
 
When:
 - a command is received
   move `forward` or `backward` or rotate `left` or `right` (90 degrees)

Then:
 - move the Rover
   if the Rover disappears over the edge of the map (the horizon), continue on the other side (remember, Mars is a sphere)

Bonus point

After ensuring that the functional requirements have been met, as a bonus point (not necessary but more than welcome), add a new feature:

Given:
 - a list of obstacles with their exact location
 
When:
 - Rover moves

And:
 - Rover encounters an obstacle

Then:
 - report back the obstacle. The Rover should stay in its previous position

Your solution

Must (These points are mandatory)

  • Fulfill the Functional Requirements stated in this readme
  • Be testable. In a way that let checking that everything is working without execute the main app
  • Be self compiled
  • Be self executable

Should (Nice to have)

  • Fulfill the Bonus point section of this readme
  • Be bug free
  • Use any design patterns you know and feel that help solve this problem
  • Be extensible to allow the introduction of new features in an easy way
  • Use any package dependency mechanism
  • Have a SOLUTION.md containing all the relevant features of the provided solution

Evaluation

  • The design and code over the usage of frameworks and libraries
  • The evolution of the solution, not just the delivered code
  • The easibility of extending the solution with feasible features