Building up tests via context and let in Ruby

One of my favorite parts about Ruby is writing tests. Here's a pattern I use frequently, which allows you to use context and let to build up state as you progress deeper into the context tree. This is best described with an example:

What's going on here?

First of all, I like to always add a describe method block for each public method of the class, and then inside it, declare a subject variable which calls that method. Then I add a let(:...) for each of the arguments to the method. This allows me to setup some sensible defaults for each argument, and only modify the arguments as needed in each context. First, I test the default arguments, like in the context "with defaults". Then I proceed to test modifications to each argument. For example, the context "with nil player" expects the described method to return nil when a nil player is passed in.

Where things get more interesting is the context "with other existing character". Here, we have a before statement which gets triggered before all of the tests in that context. It sets up state such that there's already another character generated. It expects each sub-context to declare a new variable, existing_name, and generates an object with that name. Then we have two contexts where existing_name either matches or does not match the name being generated by the function call. Under the name matches context, we have another sub-context for when that existing character is under a different player, which is treated differently. You can easily nest many sub-contexts, each with a useful description of the state that they are in. As a result, we can test all the different states of our class or database with fine granularity. That's where I find the sort of pattern most handy: checking for all the different states that are possible by changing each state option one at a time.

Finally, we can easily test each of our validations this way. The simplest example was the nil player near the beginning, which yields a nil return. Another example is the name containing invalid characters context. Here we have a very simple context which defines the expectation that the class will raise an exception when an invalid name is passed in.


Comments

Post a Comment

Popular posts from this blog

Crossing the Rubycon

I first learned Ruby about a year ago and it quickly became my scripting language of choice; a position I doubt it will ever lose, hence the name of this blog post. Here are some of the reasons that I prefer Ruby over Python, NodeJS, and PHP, for most use cases. Testing The primary reason I prefer Ruby is how great writing tests is. Tests in ruby can be incredibly concise and natural. The built in mocking, stubbing, and monkey-patching functionality is very powerful. I particularly love the way contexts can be built up with let(:...) to have very descriptive and concise tests. The philosophy If you look at a language like PHP, it has basically no philosophy behind it, at least not a consistent one. Hence you end up with all sorts of weird behaviors. For example, consider preg_match , which finds matches of a Regex in a string: preg_match() returns 1 if the pattern matches given subject, 0 if it does not, or false on failure. Gross .  Wait, where are the results of the regex match? // 
Read more

The many benefits of working in small increments

If you're a software engineer, you've likely heard of the Single Responsibility Principle  (SRP). I believe it's the single most important principle in software engineering. The simple explanation is that one object should do only one thing and do it well. Having a well defined single responsibility makes code easier to understand, change, delete, and test. The complexity of code grows exponentially with size. Two 100 line classes, with proper segregation of responsibility, are significantly easier to understand than a single 200 line one. SRP is the "work in small increments" principle for code, and the same exponential growth in complexity applies to much more than just code. Working in small increments shortens the feedback cycle, which is the best thing any organization can do to increase its velocity. Small Tasks Every task should be small - small enough to complete in less than two weeks, ideally less than two days. Small tasks are easier to write, understan
Read more

The two qualities of great software architecture

Great software architecture solves a present business need and is easy to change when business needs change. Software architects have developed a number of heuristics: patterns and principles that help to achieve these goals. A software engineer that applies but does not fully understand these heuristics may implement them in situations that run counter to the goal. To write great software, it's important to understand how each pattern and principle contributes to the goal. Entire books have been written on most of these subjects. This is intended to be a brief overview, not an exhaustive list or explanation.  Solving a present business need Most users could look at an application and tell you whether it solves a present business need, aside from some of the more subtle nuances. For example, an application may solve one need but is not secure, which is usually one of the business requirements. Some of the criteria that may roll up to this metric, depending on your business: User ex
Read more