My rspec problem: When your code is correct but RuboCop says no
So I’ve set up my development environment in a WSL Bash shell on my Windows 10 PC. I try to test code using rspec but it’s not working properly. All other tests pass except for code quality tests, which uses RuboCop to enforce Ruby style guidelines — e.g. a single space either side of an operator, or not using parentheses around a method call.
For context, this occurred during the Makers PreCourse where I’m working in a Bash shell on Windows 10, via WSL. I’m mainly a Windows user so I don’t know if this happens to macOS or actual Linux users, or if it’s just me.
I experienced this issue while working on the quizzes for Maker’s Ruby mastery curriculum.
At Makers, students on the PreCourse get matched with a student from the previous cohort who volunteer to be mentors. I discussed my issue with my mentor, and while we didn’t know how to resolve it at the time he did point me to RuboCop.
I couldn’t work out what was going wrong but I didn’t want to waste time trying to fix it when I had a simple enough workaround available: push code to the repository as soon as I’m done coding, and then go ahead and submit the quiz for grading. Quiz submission generates rspec test results that I can look at to locate and correct any style violations. At this point, even having passed the tests 100%, the code quality tests still fail when I run rspec locally. Comparing with actual rspec output from the quiz submission, I see that the rspec out I get locally is really no help at all — no indication of what style rule has been violated, or where it’s occurred.
I got through all the quizzes like this and when I finished them, I had time to investigate the problem. By now, I was a lot more familiar with Bash and how permissions and ownership work in Unix-like systems.
Running rubocop on the command line displayed its configuration and the clue was the line at the top reading
Permission denied @ dir_s_mkdir - ~/.cache/rubocop_cache
The command ls -la ~/.cache/ showed that the ownership of the rubocop_cache directory was root root — i.e. the root user and the root group
RuboCop doesn’t have root access so it can’t access the directory. It turns out that there was a simple solution:
sudo chown username ~/.cache/rubocop_cache/
This lets you take ownership of the directory and fixes the issue.
What a difference a few days makes!
This post was a story I wanted to tell in an original post here, looking at why you might prefer to use a Mac for coding bootcamps, but I thought it broke the flow of the piece so I’ve put into its own post.
