As many of the other commentators have noted, this Kata is excellent for TDD, but I had an interesting epiphany doing this exercise. I could see how my "Design" took a different turn and was heavily influenced with TDD. Without even realizing it, I went against the advice stated in the problem and "thought" threw the solution. I worked out the combinations with pen and paper and came up with some code. It was clean, efficient and had very less number of lines. But when I took a break and came back to finishing the rest of the problem, I realized the code was not readable at all. It took me sometime to figure out the algorithm/formula that I used and get back on track. I decided to throw out all the code and redo everything from scratch, this time driven purely through the tests. I landed up with much more readable code. I believe my initial solution was far more "efficient" in terms of processing, but the code was less readable. My final solution driven with TDD was far more readable, but probably less efficient and involved multiple case/switch statements. It's a tradeoff, but atleast one that I've begun to understand. I definitely suggest this kata be done twice: once thinking of the solution to start with, then with TDD. Compare the two.

It is totally worth it to do this kata twice. When I did it with 100% TDD, I had a totally different view on how the design emerged out of the test code. However, quite interestingly, eventually I end up with code somehow similar to the previous version. One main observation is, after start with 100% TDD, the method name and belonging made more sense, but also the code got messy very quickly. It happened from time to time that the code seemed not DRY at all. Then I would stop and refactor. Just as David Liu said, there was more time spent on refactoring than on coding. But after all the effort, after I got the simple, clean code I felt it totally worth it. TDD + refactor = clean readable code.

I redid this kata for the second time. Instead of naming test cases after the methods under test, I identified test cases using descriptive sentences. This helped me decuple design from the test suite. I completed the kata by stubbing out my test suite and then implementing each pair of test and implementation methods. My API pretty much ended up the same as the first time I did the kata. My test cases did not say anything about needing a grid, so I used a collection of objects, which I iterate through when looking for collisions. However, my implementation was much cleaner the second time. I ended up going all out with trigonometry, which will make it easy to add NE, SE, SW, NW directions in the future. I feel that I have a very natural API, and all of my methods are practically one-liners.

As the title suggests, what I liked most about this Kata is its "testability". The format of the examples to test is clearly specified, so all it takes is to write their tests out, and start coding to pass the tests. As many reviewers noted an object oriented design emerges naturally for the solution. For me that was because the abstractions of rover, and planet (for grid) gave an easy to communicate flow to the execution function.

This kata provides moderate amount of situations for one to consider testing. At the same time, it is also really great to see how the object oriented design evolves with the testing progress. Keeping one's object oriented design flexible and clean is not easy, but worth practicing.

I did this initially in Java, but it was not done totally with TDD. Then I redid it in Javascript with 100% TDD and added some animations for fun. Doing it the second time around made me realize how I created the different classes that I needed before even implementing the solution. However, nothing horrible happened. When I did it the 100% TDD way, I realized my code was getting messy fast and I needed to do some refactoring. I actually spent more time in my second implementation because of this refactoring step. It makes me wonder if I'm doing TDD correctly and if my experience is natural...

Fun coding exercise! Also making it a "game" made it a little more interesting for me, go figure! I also was doing much of my coding as "Test Driven Design." So when we got the assignment to re-do this Kata, I used T-D-Development. I made sure to write all of my test cases first, organize them by complexity (simple to complex), and then code everything. I notice that this development of MarsRover was much faster and more efficient. Since I was coding based on the tests, I focused on the most important requirements first and didn't even code certain things I did last time. All the tests still pass, object detection, world wrap, and the implementation was just more straight forward! I also didn't like all the if/then statements and excessive usage of case/switch statement. So for this implementation, I challenged myself to only use ONE 4-way case statement for movement and ONE for turning. Not one each for right, left, forward, back. I will pass this challenge on to you as well!

It is nice problem to enhance your design skills, to be specific , the single responsibility principle. You can design it with different classes like Rover, Game, Cell. Grid and try to keep the design simple. Over all a nice exercise. My solution is shared at https://github.com/sumeetkr/katas/blob/master/Katas_In_Ruby/

Really a good Kata for TDD and OO. When I am doing this, I decided to go a wild way in which I leverage some language feature in Java. This can help me to keep the logic of the code simple because I can reuse the logic for N,W directions in the S,E directions.

This was a great kata! It was fun to see the API emerge from my tests. The kata kept me busy because there was a lot to think about and there were a lot of decisions to be made. I ended up implementing the kata using constants and switch statements. If I do the kata again, I will keep my test suite, but take a more math based approach.

I enjoyed this kata and think it was well worth the time spent on it. It is a good OO exercise since it really makes you think about what needs to go where. This kata was also interesting from a TDD perspective since it involved a bit of plumbing work on support classes (i.e. position handling, map definition, etc.) before I could get to the "fun" parts related to moving the rover around. I think this kata should be expanded to include an interesting algorithm problem, like finding the most efficient path between two points on a grid with obstacles. I have actually recommended it to my nephew who is learning Ruby and needs a bit of work on OO design principles. In his case, he is learning Ruby basics and this exercise can also be useful for him, even if he doesn't use TDD yet. Hopefully, we'll see posts on this site from him in the near future!

This kata is good for TDD beginners as it asks for tests ranging from boundary conditions to functionality testing. It also made me think about code reusability and readability, as I spent some time thinking about how to store the data required efficiently.

I felt this kata was easy but thinking from TDD of point made it exciting and challenging. I would recommend this kata for everyone who are starting off with TDD and object oriented programming.

The problem described in this kata is not very difficult to solve. But solving it by adhering to OO principles and TDD can help to reflect on your code. I started off by writing tests for the first steps described in the kata to make the rover move and turn. I ended up figuring out the solution and then implementing the code to make the tests pass. While trying to implement the next few steps to factor in the spherical grid and obstacles, I had to rework my code and change it considerably. I would try this kata again to let tests drive the design completely and see how my code changes.

This kata contains sufficient details to take care of, making it a good one for practicing TDD. I started by creating classes and methods that fulfill basic rover moves and then built higher level of abstraction based upon them. TDD worked well and guided me toward a clean interface design.

This Kata is very good for test driven development. It also demonstrates the power of TDD to keep the integrity of a program with multiple classes and many lines of code. As there're many restrictions, TDD can help make the code work as expected. The character 'command' challenges programmer how to map it to the operation of the Mars rover, as well as how to handle incorrect input to avoid mistake.

This is a good example for testing different unit test framework for different language. It is also a great starting point for people who want to learn TDD.

This is the perfect exercise for TDD. I wish I had taken this up earlier. Very simple kata, going stepwise on the requirements went well.

The kata has a very good combination of OOP and TDD aspects to it. It requires a really good OOP design if the good has to look clean and work efficiently. But the number of possibilities/conditions in the kata makes it difficult to come up with a good design at the beginning and thats why it makes a good candidate for TDD. I had to go back and forth between tests and the design, adding/modifying methods to the classes every time I found a test case failed. It was a chain reaction! If I reflect on my approach, I probably followed TFD - even though I changed design a little by adding/modifying methods in classes - to develop the kata. Maybe I should force myself to follow TDD and see the difference in the result. Old habits are hard to change but I sure will try to change next time!

I highly recommend it to learn TDD. It was easy to see the design evolving from scratch. The kata forced me to think of one requirement at a time. Confident that my test cases are perfect. Usually with other katas I always check my test cases with a posted solution. Also this kata helped me refresh my memory on some basic java concepts. 

This is a nice kata to see the value of test driven development. There are some tricks involved, but TDD will reveal them for you as they lie around the edge cases.

This kata is good for TDD, it has a bunch of edge cases that need to be taken into account and it allows for incremental design

I did this kata by following TDD. However, in the journey I found that I kept exposing internal member functions as public because I wanted to test my code thoroughly. So, when my implementation was done, there were too many public member functions that were supposed to be hidden in the class. I realized that I should have taken OO design into account along the way. This is a good lesson learned from this kata.

This kata was great to see the power of TDD to evolve the design. It requires a bit of selfcontrol to avoid jump to think in a design, specially because the problem is simple. However, if you follow line by line the requirements of the kata and implement them in order, you can see how the design naturally evolves according to the new needs (and refactoring). With this kata I learnt that TDD generate economy of thinking, design and code because you only need to cover the current needs of the application and not spend time building for future hypothetical needs.