Chess TDD 13: Moving On
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.
[…] Chess TDD 13: Moving On – Erik Dietrich […]
“… when the TDD’s over… and I start writing initial integration and edge-case-type tests…”
Any recommendations on resources in THAT arena? Y… y’know, just in case any of your regulars have somehow managed to be almost-10-year vets without a single minute of automated testing, anywhere in their careers. It’s highly hypothetical, of course, that such a thing could happen…
(Thanks again for this series.)
Recommendations in terms of what? Like, which frameworks and tools to use? Or more like how to write those kinds of tests?
(I could conceivably do a post on this, describing how I tend to approach these sorts of tests)
Sorry, disappeared for a bit.
I meant the latter.
No worries. I’ll add a draft to address this. 🙂
Have you considered something like Trello for managing your TODO’s? If only for the sake of being able to move items around easier it would save the constant reformatting in Excel.
I use Trello daily, but I’ve always used it for tasks a little less granular. I have a Trello board that’s actually called “Daily” and the kind of tasks I put on it are “Record code for next TDD video.” I think what’s steered me away from the kind of usage that you mention is something you don’t necessarily see here, which is that there are times that I use the nature of a spreadsheet to define different columns on the fly or keep other “sub” or “meta” lists inline. Bear in mind, I don’t think any of this is… Read more »
Still way behindm but now i finally have a tabket which supports your resolution, so I might catch up 😉
You could make Matches an extension method. That way your code won’t contain test-only code with primitive obsession, and your tests still read clean. Another thing wich I use a lot in situations like this is write a method with asserts. AssertListContainsCoordinate (but I think it’s worse in this case; I mostly use it in crappy integration-like unittests where I want to encapsulate some code to show what the test is actually doing)
Extension method is certainly an option, and one that I might do if I felt that the functionality didn’t make sense in the class. One thing I use extension methods for a lot in unit tests, typically, is creating a concept like .ToEnumerable() or .ToList() where I can pass it a single T and get back a list containing only that thing. That seems to come in handy over and over again in testing situations. As for an auxiliary assert method, I’ve never really felt comfortable with that approach, though it’s more of a gut feeling than something I can… Read more »