Chapter 4. Test Driven Development

4.10. Exercises

You have just got acquainted with a new development method, which promotes writing tests before actual implementation. It is time to see, in practice, what you have learned. The exercises in this section are not so hard from the point of view of the complexity of the tasks. The point is to focus on the TDD rhythm and not on the algorythmic gotchas. When doing your homework, be extra careful about following the TDD, and doing everything in really small steps. Good luck!

When working on these exercises, remember to obey the "never write code unless you have a failing test" rule!

4.10.1. Password Validator

When creating an account, it is often required that the password should fulfil some strength requirements. It should be X characters long, have at least Y digits, contain underscore, hash, and a mixture of lower and capital letters, etc. Your task is to write a method that will validate a given password. The set of rules (requirements) with which you will be verifying the passwords is up to you.

4.10.2. Regex

If you have a problem, which can be solved with regular expression, then you have two problems.

— Wisdom of the Internet ;)

This example requires you to write a method which, given a String, returns a list of all numbers taken from that String that have 3 or more digits. Table 4.1 gives some examples of expected results for various input strings.

Table 4.1. Expected outputs of regex method

4.10.3. Booking System

Your task is to write a (very) simplified version of a booking system. In fact, it can be written as a single class, which should:

•return a list of booked hours,

•not allow a particular hour to be double-booked,

•deal in a sensible manner with illegal values (provided as input parameters).

On the constraints side (to make the task more appropriate for practicing TDD), the system:

62

Chapter 4. Test Driven Development

•has only one resource that can be booked (e.g. a classroom, a lawn mower, a restaurant table, or anything else that makes sense to you),

•has no notion of days, or to put it differently, it assumes all reservations are for today,

•should only permit booking of regular whole clock-hours (e.g. it should not allow a booking from 4:30 pm. to 5:30 pm.),

•is not required to remember any additional information concerning the reservation (who booked it, when etc.).

63