Nothing complicated here.
Only thing I did was wrote out separate methods for handling each type of operation (addition, subtraction, multiplication and division). No. it's not necessary with simple math, but I think it's good practice to apply single responsibility in every situation so that it becomes a part of how you think as a programmer.
One thing about any given challenge is that there is the opportunity for simply solving it as presented, and then there is the opportunity to look at the challenge in a broader, real world sense.
The broader sense here would be how the user would use a program like this. If the user is going to be entering a string as an operator, you will want to handle for different possible things they could enter for the operator. My initial solution handled for anything other than the four we may be expecting. But we can go beyond that just thinking about how users are.
So with that in mind ran a quick refactor.
You wouldn't want the user to be met with an error if they enter "Multiply" instead of 'multiply,' or you'll want to give them guidance of sorts. The reality is we can address this simply by applying Ruby's downcase() method to the operator value when it is submitted, that way if the user does provide "Multiply" we will downcase it to "multiply" and the script will still execute correctly without the user having to enter the value a second time, or being met with an error.
To test this I added two of my own tests beyond the tests that the writer of the challenge had provided and made certain they passed. The last two (lines 6 and 7) were the two I added with the refactor.
There are other things we can do as well, handle to make sure any number they enter is a valid fixNum, or address decimals, provide some enhanced feedback when the operation completes.
The point is, even on simple challenges, take that challenge beyond simply solving it and look for real world applications of how you can think about it. Because no one actually needs you to recreate a calculator. Just sayin.'