In the last bunch of installments of this series, I’ve implemented methods for pieces to determine where they can move on a board and/or done some refactoring. But I’ve ridden that train as far as I can, now having implemented all of the pieces, so it’s time to shake things up a bit. Another thing that makes this post different is that I’m going to try a new way of structuring my test classes.
The other day, in response to a comment, I made a post about test initialize methods and Steve Smith commented and suggested an approach he described in detail in this post on his blog. The gist of the idea is dispensing with the old stand by of having a test class for class Foo called FooTest and instead having the name of the test class describe the context of the test, BDD-style. I found this idea immediately appealing and decided I’d try it out in “some project to be determined,” but what’s the fun in that? Once an idea settles in my head, it’s hard for me to shake it, so instead of doing it later, I’ll do it here, now, publicly. Apologies in advance (I’m typing this part before recording the coding) if it results in a bit more floundering, but I think it might be fun for us all to learn together. If nothing else, you’ll get to see how easy or difficult it is to adapt to this convention.
Anyway, here is what I accomplished in this clip:
- Got started on complete move calculation implementation.
- Defined the setup of complete board for a lot of tests.
- Established a new pattern for constructing tests.
And here are some lessons to take away.
- When you are exposed to a new practice or way of doing things, there’s no time like the present. While it may not always be practical to ram the new stuff into some time sensitive project, experiment and try it out to see how you like it. Trying out different techniques keeps you sharp and helps you avoid falling into a rut.
- When you haven’t looked at code in a long time, it’s easy to lose track of internal implementation of classes. One of the real perks of TDD and having a test suite is that it’s easy to poke and experiment to see what’s going on without fear that you’re going to break something.
- If kept concise and focused, a bit of yak-shaving in your implementations can be pretty productive. Always be looking to improve on your code’s readability, elegance, and efficiency if you can.
- It’s important to keep your test suite as communicative and descriptive as possible, and you should always be looking for ways to help you toward that end.