Think differently when the current tests fails

Tagged As:

This is a lesson learned from work. SO we use Rials in our project at the workplace. SP for a new requirement, we had to have a validation for a particular attribute of a model.   The requirements were specific on where the validation should happen. Say for example for what controller actions.

However, the initial idea was tho have the validation at the model so that it will be validated on create and update. The idea was that every controller action that matters the new attribute validation would automatically be validated.

The approach was working great. However, after the existing tests suite has run, the results were about 70% failure. So we looked into the test code and noticed that the attributes set for the models were not following the rule. Therefore the initial thought was to fix the specs and make them pass. So we spent several hours altering the specs and running them to make sure they pass. Then we came across a test that acutally indicated our approach caused an existing functionality to break. Meaning that the rule should not be validated when performing that particular functionality.

So then we thought about a different approach and ended up using contexts in Rails. There we were able to tell the model only to validate the attribute when it is in the given context. As a result, there were only few tests that failed at controller level testing. We quickly fixed them and added specific test scenarios to cover the new requirements.

So lessons learned:

When the code change breaks a lot of existing test, it is most likely because that the app functionality is broken. So think of the bigger picture of the code change and come up with a solution that would impact less part of the application as a whole.