"Mars Rover Space Travel Rover"
by WikiImages is licenced
under Pixabay License
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).
- Hardcore TDD. No Excuses!
- Change roles (driver, navigator) every 5 minutes.
- No red tests while refactoring.
- Be careful about edge cases and exceptions. We can not afford to lose a mars rover, just because the developers overlooked a null pointer.
For this kata, you can leverage GitHub Copilot to help you to write code. This kata, is an opportunity to experiment with Copilot to:
- Help you incrementally design code
- Experiment with GitHub Copilot in a safe zone to get better at using it
- Understand its limitations and how to work around them
- Compare it to other tools and practices (ex: Unit Tests, Linters, Automated Refactoring, etc.)
- Learn how to combine those tools and practices together
- Start without Copilot when implementing first Command. The goal of the kata is to learn the TDD flow. Once you have finished the first command using manual TDD by the book, enable your copilot. You can for example ask it to convert the first tests to parametrized tests. Continue with Copilot, but stick to the TDD loop.
- Always stick to TCR/TDD cycle, and see how Copilot helps for the different steps
To get the best out of Copilot, you can try these:
- Take the opportunity to increase your knowledge on Software Engineering by asking GitHub Copilot to propose
implementation variants.
- Inline chat:
Propose 5 different ways to rewrite this code and evaluate each using the perfection game - Discuss as a group the proposed answers and agree on the one to pick.
- Inline chat:
- Leverage on copilot to convert your unit tests to parameterized tests.
- Experiment with different approaches to parameterized tests, and pick the one you prefer.
- You may be tempted to come up with a single parameterized tests for everything. This might hinder test readability. Keep in mind that the intent behind tests is to make them easy to read and understand. Try different approaches to come up with an accurate balance between readability and factorization of test code.
- Experiment various prompts using standard engineering vocabulary and see how it impacts the quality of the suggestions (cf. Refactoring Guru website)
- Try to do the same refactoring with an IDE-automated refactoring and with GitHub Copilot.
- Copilot tends to generate giant steps. It will typically propose to implement a lot more than needed to pass the current test. Delete what is not needed: Copilot can suggest it later anyway, with better context!
- Copilot will confidently propose wrong tests. Be very careful and double check every test case that it generates.
- Copilot has different UIs: Autocomplete, Inline Chat, Copilot Edits, and Chat. Use each for what it is best at.
- Copilot context is local to each user session. This can be a problem and an advantage!
- 😔 Our license of Copilot has restrictions on public code. This kata is public code, so sometimes, especially when working with many lines of code, it will refuse to answer! Play with a smaller context and a different prompt. We don't have a real fix yet.
You can fill it from here
- TCR (Test && Commit || Revert) wrapper utility
- Collaborative timer for pairing or mobbing: mobti.me or agility timer
- 2-hour Randori in Pairs
- Designing with TDD
- Baby Steps
- YAGNI
- Code Smells
- Refactor on green bar
Kata-MarsRover and the accompanying materials are made available
under the terms of the MIT License which accompanies this
distribution, and is available at the Open Source site
See ACKNOWLEDGEMENTS.md for more information.
Damien Menanteau |
Ahmad Atwi |
Philippe Bourgau |
AntoineMx |