How should I split my code to make it readable, maintenable and testable

A computation is always made of a parsing phase followed by an execution phase, so maybe they need to be in the same class?

This is not a correct reasoning. Single responsibility principle aside, one intuitive way to consider whether something should be split or not is to think about a possibility to swap implementations.

Take the parser, for example. Right now, it parses your pseudo-Excel language to get a list of instructions. Would it be reasonable to imagine that you could give the same list of instructions by parsing a different language? Or by, say, doing a query to a database? Or by a simple deserialization of a JSON file?

If the answer is yes, there are chances that the abstraction you created makes sense. As there are chances that you will swap it at some point.

One example of such swapping is when you just start the project. Say you want to focus on the executor, and you have no intention to make the parser right now, because it's tedious, or just not fun yet. Great. You create a basic implementation, something very simple that you are able to draft in ten minutes. And then you focus on the actual fun of the executor.

Another example is, indeed, unit testing. To test the execution part, you shouldn't care at all about how the instructions are created in the first place. The two things you care about when testing the executor is that a given instruction or set of instructions produce a given result, and that getting those instructions takes nanoseconds or microseconds—you want your tests to be as fast as possible.

This brings us to your first question:

Am I trying to perform unit testing (for OperationService) where it is in fact integration testing?

Absolutely. Changes in your parser shouldn't break the unit tests of your executor. Changes in your executor shouldn't break the unit tests of your parser. Now, integration and system tests cover a larger code surface, and therefore can (and often will) break when one of the components misbehaves.

And this is an essential aspect of the aforementioned single responsibility principle. If you change the way you parse things, you should be changing your parsing class. Not your executor class, or some huge class that contains absolutely anything. Which brings us to your other question:

Do my classes correlate so much that they belong to the same unique class/file, which also make it less readable (but more testable in that case) if I do so?

Parser and executor have practically nothing to do with each other. Which is why you're correct in making two separate classes.

Your question shows one simple, but huge misconception: apparently, you believe the subject of a unit test, the unit, must be a class, and each class must have its own unit tests.

But that's not the only correct way of doing things. The "unit" of a unit test is what you want it to be. This is your decision. Sometimes, it can be a class. Sometimes, it is component which is made of multiple (tightly connected) classes. Sometimes, it starts as a class and becomes a component with multiple classes by refactoring. Of course, there are certain rules-of-thumb when a component should be seen as a unit and when not (testable in isolation, being fast, no environmental dependencies, no database involved and a few more), but those are heuristics, not laws, and there is always a matter of taste and experience involved.

Now lets apply that simple wisdom to your questions:

Am I trying to perform unit testing (for OperationService) where it is in fact integration testing?

When you define your subject-under-test as the unit formed by the three classes, then you are still unit testing. Dogmatic thinkers from the "the-unit-of-a-unit-test-must-be-a-single-class" thought-of-school may say it is an integration test, but in the end, when the test achieves its goals, then it is irrelevant how it is categorized.

Does my class splitting makes sense for that purpose?

Absolutely - a task which consists of two subtasks, both enough complex enough for justifying a class on its own, clearly helps you to organize your code in a sensible way.

does my classes correlate so much that they belong to the same unique class/file, which also make it less readable (but more testable in that case) if I do so?

That's a matter of code size, a matter of which programming language you are using (does it require each class to be in a single file? does it allow nested classes?), a matter of tooling (does your IDE provide a class browser or only a file browser?), and to some degree a matter of taste.

a computation is always made of a parsing phase followed by an execution phase, so maybe they need to be in the same class?

I see no reason why the former implies the latter.

Recommened reading (with a clear statement against dogmatic thinking): The Way of Testivus.