MarkUs Blog

MarkUs Developers Blog About Their Project

RSpec testing in MarkUs II

without comments

MarkUs is the robust and reliable application where testing is used as the main component to make sure those qualities persist. I knew nothing about testing before starting UCOSP this term in January of 2015. Besides the fact that testing is very important for the known reasons (Duh). When I began learning RSpec I realized the philosophy behind writing robust code: consider all the possibilities of how your code can be wrecked before writing it. Are you writing a form with a field prompting for user’s date of birth? Think about dates like 99/99/9999 or javascript code that might end up in that field. Crazy stuff happens, so it’s faulty to write code only assuming the best-case scenario where user actions are always coherent with the functionality implemented.

The Behavior Driven Development (BDD) seems very logical and even optimal for applications like MarkUs. But adopting it means that all the developers should have in-depth knowledge of how testing works. It’s seems unlikely to happen due to the distributive nature of the application and the fact that many people who work on it are coming and going just like me. After spending my term on MarkUs working with RSpec I can say for sure that I’m not even close at becoming pro at testing. So forget about BDD and let’s see what I’ve done over this term.

The tickets I was working on mainly concentrated around different sorts of testing. I started with the easiest kind that involved unit testing where you test a single function to make sure it produces appropriate results using arbitrary scenarios. Sometimes it’s difficult to come up with a good scenario. You have to think about what function supposed to do and test that, but then you also have to consider wild (not too wild) possibilities that could break the function. Writing passing a test is easy, but most of the time I was only satisfied when I was able to break something that resulted in failing test and required fixing.

That happened when I began working on CSV upload functionality for Simple Grade Entry form. The upload relies on rails library parsing methods that are not ideally robust to begin with. So it’s very important that the file passes all the checks before entering the parsing stage. My wild (but not too wild) failing scenarios included checking for: presence of EOF character, appropriate EOL characters, non-CSV files that are pretending they are CSV (sneaky spies!), etc. I also discovered that any file passed through CSV upload would overwrite the original template. Even though this functionality is required for other parts of MarkUs, I thought that it could potentially cause some troubles along the way. Now this concern is handled and corresponding RSpec tests are in place.

RSpec is a powerful testing framework that possesses both great readability and writability aspects. Although it’s not good enough on its own for html parsing (requires Nokogiri), and javascript parsing (requires Capybara/Selenium pair which is not a stable solution for vagrant box developers).  I also found out that RSpec is not multi-thread-friendly and because of that I was unable to finish the last issue that required testing forked processes. Nevertheless, there are currently efforts made by the RSpec core team and, hopefully, we will soon get the capability of testing parallel processes.

I greatly enjoyed working with this test framework and its object-building sister – FactoryGirl. The biggest challenge I was facing is understanding of sometimes complex relationships between different MarkUs entities. And in-depth understanding is required, because there is no way to even start testing without a good idea of how different elements co-operate with each other. And then you start building factories, which have to follow the rules of multiple associations, validation and other model requirements. Testing helps a developer to get almost intimate with the code, so I believe that this term I became not just a better coder, but improved as a programmer.

Written by Maryna Moskalenko

April 10th, 2015 at 8:22 pm

Posted in Uncategorized

Leave a Reply