The Password-Strength Checker Design Kata – Part 1

In two of my three technical courses (Essential Agile Engineering Skills and Essential Test-Driven Development), the first major topic I cover is refactoring, its role on an Agile software development team, and its role in software design.

Sometimes, but not always, the participants have the time and inclination to come back to the topic of software design. I have an optional learning “module” that—at a minimum—covers Kent Beck’s “Four Rules of Simple Design,” and how we look at the Open-Closed Principle from an “Agile” standpoint.

Before we do a lot of talking, however, I give folks a lab (or “kata”). Since we don’t always get to it, I’m offering it here for you to experience, if you choose. This post will likely be one of three: The lab has two parts, and then I’ll summarize it in the third post.

I encountered Part 1 of this lab many years ago and was delighted to see just how quickly certain issues arose. I’ve added to it, which is why it will be split over a series of posts. (In Part 2, I’ll reveal why I had to invent a “Part 2.”)

Part 1 may take you 10 minutes. It may take you a month. And, if you choose to try it, you can send me e-mail with questions or solutions (Rob.Myers@agileforall.com), and I will [infamously] reply within 30 days. That conversation may (or may not) have impact on the third post. You could also wait until you’ve had a chance to read all three posts, but that’s like reading the last chapter of a mystery novel: “Spoilers!”

This lab may seem deceptively simple. And, in some ways, it really is simple. It’s always an instructor’s dilemma: The labs have to be simple and clear enough to be completed, but have to convey the intended lessons. They have to be toy examples, but the technical solution to the challenge has to be a real and valuable technique.

Think of this as a microcosm of your usual software development challenges. Treat it as though you were really getting paid to build what is asked, and be extra-sensitive to testing constraints, design forces, and code-smells that arise. Imagine that this system, and each of those smells, are much larger and more critical than they may seem for such a tiny lab. Utilize the knowledge, skills, and tools available to you.

That’s not to suggest that you pull in every framework or design pattern you’re familiar with. No need to over-engineer or show off. 😉 Again, this lab is uniquely tuned to be a stand-alone software design kata. The best designs are simple designs. And simple isn’t always easy.

The Password-Strength Checker – Part 1

Technical requirements:

1. Use Test-Driven Development. I.e., write a failing test, then write the code to make it pass, then refactor a little, before writing another test. Yes, that’s really ONE TEST AT A TIME! It might help you to know that part of TDD is having a short to-do list of things to test and things to refactor. I tend to prefer a 3×5 index card, so that the list doesn’t get too long.

2. You can choose any programming language with a simple unit-testing framework.

3. You are encouraged to pair/mob on this. Via Zoom, perhaps. Or, perhaps you have a parent, child, or partner living with you who is interested in learning some of this programming stuff. I believe TDD-plus-pairing is the best way to learn programming, or a new programming language, or an unfamiliar API. Of course, you have to learn the unit-testing tool first.

Product requirements:

1. We need a simple, in-process, easy-to-use password-strength-checking API.

2. The caller shouldn’t have to have knowledge of what checks are being done to the password string.

3. A simple Boolean return value of true (strong enough) or false (too weak) is wanted.

4. In order to be an acceptably strong password, a string must…

[ ] Have a length greater than 7 characters.

[ ] Contain at least one alphabetic character.

[ ] Contain at least one digit.

That’s it!

When you are done building it, please answer the following questions for yourself. (I recommend you write your answers down someplace where you won’t lose them in the next four weeks.)

1. Did you have a prior test fail when a subsequent test was made to pass? If so, what did you do in response to that issue?

2. If asked to alter the API, what sort of changes would be easy to test and develop? What changes might be more difficult to test and develop? Why?

Have fun with it!

Want Part 2 before it gets posted here? Sign up for my Developer Essentials Newsletter HERE! and you’ll receive it via e-mail.