Refactor Like A PRO: Testing Your Code

In the previous part about code refactoring techniques, we talked about the some reasons to refactor your code and how to plan out the procedure. You already know that the purpose of refactoring is to make your code more readable and well-structured. More importantly, it allows you to make sure that adding new functionality won’t break anything. However, the devil is always in the details. In addition to general improvements, proper code refactoring can also solve a whole bunch of smaller issues that you may not know about.

So how can you get the most out of this procedure? The easiest way to make sure that you didn’t forget anything and save time is to involve a QA engineer, who will prepare a detailed specification and check things manually. Ultimately, when it comes to detecting bugs and defects, only a real human is able to ensure a holistic approach and properly check if the application works as expected. However, this doesn’t mean that you can forget about writing tests, hoping that the QA engineer will do the whole job for you. Tests are very important for developers themselves in the first place and here is why:

• The project becomes easier to understand (which means you can spot bugs faster).
• Tests allow you to check the most common issues.
• Tests allow you to avoid repeating mistakes..
• Finally, the biggest benefit of writing tests is that they increase the speed of the whole refactoring procedure (as soon as you’ve written a piece of code, you test it straightaway; so there is little chance that a critical bug will pop up in the future).

What you should do before writing tests for your code

On the Internet, there’s a widespread belief among developers that you should write tests first, and only then figure out the code. Let me let you in on a little secret, here’s a thing. As you write tests, you’re going to need to get to the bottom of things anyway. However, at this point, you don’t need to think about how you can rewrite this or that piece of code. What you do need is to clearly understand what the code is supposed to do.

Chances are you may have to deal with spaghetti code, which is often a real torture, especially for experienced developers. The easiest solution, in this case, will be refining that code to match the style guides that you’re used to working with or the ones that are considered generally accepted in your company. The most important rule to remember at this point is that you should never rewrite the logic of the app.

With that in mind, you can proceed to lines and symbols. If you can use a symbol, go for it; otherwise, use single or double quotes. If there is a line that is transferred to an unknown function, it’s better to leave it as is. After that, the check spaces and indentations. Make sure the code is well aligned. Another thing you need to pay attention to is the order of defining in classes.

You can use our cheat sheet to place things in a proper way:

1. Plugins.
2. Call of class methods that initiate new methods.
3. Call of class methods that configure it (gem methods go first; then go Rails methods).
4. The “initialize” method (if needed).
5. Definition of class methods.
6. Definition of instance methods.

The only thing you can change here without any serious consequences is “if” (you can replace it with the ternary operator).

Covering logics with tests

The approach to writing tests before refactoring is different to how you do it during the development process. For refactoring, you need integration tests. In a nutshell, they mimic user behavior and allow you to check whether the result satisfies specified requirements. Even if the code is poorly written, these tests will show whether it works or not. However, integration tests have a disadvantage: they are slow. For each query, you need to launch a Rails server along with the whole stack of technologies.

Because of that, integration tests are usually written only in cases when everything functions as expected. Here is an example. Suppose we have a web page to check. On that page, integration tests will check only specific important data, e.g. only the first two columns of the table. As for other cases (e.g. invalid results, what types of data were received exactly, whether the additional data was created in the database, etc.), they are checked with quick tests for controllers, models, etc.

With that said, you need to check both types of cases. In addition to checking the content on the page, you need to check the database and make sure that all the necessary records are created. Again, you need to make sure that the whole functionality operates as expected, including even the tiniest details.

Preparing QA specifications

One of the keys to making a helpful specification is a proper introduction. It should contain only the basic details like:

• what the project is about;
• what the purpose of the feature is;
• how it’s supposed to function, etc.

This information will help developers to look into this or that feature and, thus, implement it much faster.

Pro tip: try to fit your specification into 20–39 pages; otherwise people may find the information lacking or excessive.

In JetRuby, we use certain verbs to make specifications easier to understand:

• must/must not;
• should/should not;
• may/may not.

Accordingly, must is used when describing a mandatory feature, should — when the requirements to the feature may change, may — when the feature isn’t elaborated and is planned for the future.

As for the structure of the document, it should include the following points:

• Introduction;
• Purpose (this is where you should describe the purpose of the specification);
• Description of the contents (scope);
• System description or system overview (here you should describe the initial state of the system before the implementation of the feature).

In JetRuby, we also make sure to include references and definitions. The very specification consists of use cases. They can be functional (describe how the interface will look like and how the user will interact with it) and nonfunctional (describe performance requirements). Each use case should be documented in the form of a table. In its turn, each table should contain the following points:

• summary (a brief description);
• rationale (why the feature needs to be implemented);
• users (the list with the types users for interaction);
• preconditions (description of the system before the case);
• basic course of events (description of the system during the case);
• alternative paths (alternative working scenarios of the case);
• postconditions (the state of the system after use case).

Finally, when writing specifications, remember about the following rules: visualize future functionality, don’t modify basic elements, don’t go into obvious detail.

Summing up

In covering the code with tests you make sure that it’s easy to maintain and work with. Writing tests is a procedure that requires time, but the reward for your efforts will be clean and reusable code, which won’t pose any challenges for other developers. In our next article, we’re going to elaborate on the very process of refactoring your code: most important steps to follow and things to consider. If you have any questions about code refactoring techniques, feel free to ask them in the comment section below! May the style guides be with you, guys!