DEV Community

Discussion on: Should I test initialize?

Collapse
 
lpasqualis profile image
Lorenzo Pasqualis

Yes, all Ruby code should be tested.
Ruby is a non-compiled language and the only way to know if the code is even remotely correct is to run it. That could be said for all languages, but in compiled languages you get at least some level of analysis done by the compiler. In Ruby you are on your own. Even the most obvious issue might surface only at runtime.
Now, I am not suggesting that you should go crazy trying to get to 100% code coverage. In theory it would be a fine goal to have, but it in practice is simply too expensive.
When it comes to initializers that have a complex logic with many corner cases, it is particularly important to have tests and strive for a decent code coverage. The reason is that initializers are the entry point for the operations of a class instance, and defects in an initializer are particularly problematic. They have a high probability of creating issues in the future as you use the class in different ways.
Now... if an initializer is particularly complex, I'd question the design. A class with complex initializers can probably be refactored and its functionality distributed to simpler objects or refactored to be contained to more generic methods that can be tested separately.

Collapse
 
databasesponge profile image
MetaDave 🇪🇺

I would definitely highlight the issue of complex initialisers being questionable. The purpose of the initialiser is surely to set instance variables, and I would see anything else that it does as a code smell.

That reduces the initialiser to setting instance variables, and the values of those instance variables may not by themselves be publicly available.

Furthermore, if you test an initialiser it seems to me that you should be testing an interface between your class and the rest of the code base, and it is generally that interfacing action that should be the subject of the test.