My code behaves different between and bundle exec rspec - why and what can I do?

This is regarding the Enumerable Exercise, for_cs_sake(string) problem.

I got the array of the words with C in both cases: [“sticker”, “ack”, “lock”].

After sorting by c_distance(word), in the array becomes [“ack”, “lock”, “sticker”] so the answer is “ack”.

However in bundle exec rspec after sort the array becomes [“lock”, “ack”, “sticker”] and it returns the answer as “lock”.

The code is exactly the same but it gives me 2 different results 2 different environments. Why and what can I do?


I’d have to look at your code and the spec file to see exactly why it’s giving two different results.

I’m a student myself, but --if it matters–most of the feedback I’ve gotten from AA staff so far seems to indicate that passing the RSPEC tests takes priority, so I guess you need to look at the spec file and see why it’s returning the result it is.

I will say that I’m finding it incredibly frustrating that --unless I missed a chapter somewhere-- we’re basically expected to be fully fluent in RSPEC without ever having received any substantial instruction in how it works.

1 Like

Here is my code for that part of the exercise. Run it in rspec. Run it it They give different results! :tired_face: Put some “puts” to see the arrays before and after the sort. They sort differently!

def for_cs_sake(string)
words = remove_punctuation(string).split
closest_c_words = “”

closest_c_words = {|word| word.include?(“c”)}
closest_c_words.sort_by! {|word| c_distance(word)}

def c_distance(word)

def remove_punctuation(string)
string.gsub(/[^a-z0-9\s]/i, ‘’)

I believe you. RSPEC apparently interprets some Ruby commands differently than does…good to know, I guess.

I am a bit curious now…if I had the time available, I’d just go back and refactor each individual method, one by one, until I’d isolated the problem.

1 Like

Barbara, your code runs exactly the same for me in both environments - it produces the correct result when I run the RSpec suite as well as when I run it in I’m not sure what issue you may have seen here, but rest assured that you have a working solution!

That’s crazy! I was having this issue too, but with the given solution. I ran the given solution using rspec and it gave me the same error (returned “lock” instead of “ack”). When I run it on, however, it gives me the right answer.


This is a bit of a shot in the dark, but what version of ruby do you have installed locally and under what OS?

It does look to me as though the sort effect by sort_by is not stable when run in your local environment but is stable when run in (Or, rather, is behaving as does a stable sort on the inputs it is being given.) See for more. But, essentially, a stable sort is one that won’t change the order of items in a sorted array when those items compare as equal. So a stable sort of [5, 5.0] will produce [5, 5.0], but an unstable sort might produce [5.0, 5]. One of the answers in the link that I provided suggests that ruby’s sort is not stable on Widows, was not stable for older ruby versions on linux, but is now stable for recent ruby versions on linux.

This might be your issue.

(Edited to qualify claim that the sort is stable on to the claim that it is behaving as does a stable sort for the particular inputs it is being given.)