Blogs

Previously we took an initial look at what Redis is, and which of its features Code Crafters (CC) expects us to implement in their course on the subject. The first thing we’re being asked to add to our Redis implementation is a simple TCP server. Because this is the first step in the project, the repository that CC starts us out with already has this simple step written for us (although commented-out).

What is Redis? In my last post, I mentioned that I would be attempting Code Crafters’s Redis course, which challenges us to write our own, simple version of the popular open-source data structure store. It’s important to know what we’re building first before we start, so I want to go over, at a high level, what Redis is and what it’s used for. As for that second part, Redis is a pretty generic tool that can support many different use cases.

Recently, an up-and-coming engineering development platform caught my eye. If you’re not already familiar with it, it’s called Code Crafters, and the idea behind it lines up so well with the spirit of my own blog that I knew I needed to give it a try and write something about it here. Disclaimer: this is not a paid or endorsed review, I’m following my own genuine curosity here. What is Code Crafters?

Some Updates Is there anyone out there? If there is, I just wanted to mention a few updates since it’s been a while since my last post. I got home recently from a lengthy vacation and have been just trying to catch up after being away. I’ve decided to put the test framework project on hold in favor of some more concrete (and less self-referential) projects, and I think the Evergreen framework will be better for it in the end.

Setting Up for Success In the interest of transparency, I ran into a few issues while writing this post that had me rethinking the structure of everything we’ve done so far. But I think that’s OK, because it was a learning experience, and the final result will be a better testing framework at the end of the day. I haven’t completely decided on exactly how we need to change things here, but in this post I’ll walk through the progress on our current implementation that lead to the realization that we need may need to backtrack a bit.

We’re still just getting started with building out our testing framework. Last time we broke out our code into multiple files, but we’re not done with the refactoring step of this first requirement yet. Our run method calls the testMethod directly, regardless of the name we pass into the Test factory function. Because we have a working (though still partly manual) unit test, we don’t have to “generalize purely with reasoning”, as Kent Beck states in Test-Driven Development (which is the guide with which we’re following along to build this framework).

This post is up a little later than I wanted it to be, and it’s a short one. I expect to get in a rythm eventually, but as I’m building up momentum, some of my posts might be on the shorter and/or later side. Last time, we took the very first steps in building up a simple unit testing framework. Get caught up here. The first thing we want to do is update the test (the main function, in this case) to use the actual test interface run() instead of calling the method directly, like we are now.

A single step This is the first post. I know that “a journey of a thousand miles starts with a single step,” but I’ve been really putting off getting started on this for some reason, probably from a fear of doing it “wrong”. But the truth is, I definitely will. “Don’t let perfect be the enemy of good”, they say. I could probably sit here and list off sayings all day, but that’s probably just more procrastination.