On your first question: Do you mean by side effect the internal state of your aggregate object? The Given-When-Then fixture test treat the aggregate as a kind of black box. So indeed, there is no real need to test the internal state. It is only important that the right events are applied.
So for example, you might even end up with aggregates without any fields (expect the ID) as your decision logic does not depend on any internal state. As a rule of thumb, I only save data transported in an event in the aggregate object if I need it later to decide which events to apply or if it changes the data applied in an event.
If you keep that in mind, you don't really have to test the internal state. You simply configure an aggregate with specific events in the given clause (build up some state) and then apply a command. If the correct events come out... you're done.
On your second question:
Business validation should go in the command handler. So everything should be validated before the apply
method is called. One reason for this: Imagine a system in which the validation logic changes over the life time, but you have to deal with old data which was entered when the system was introduced. If the validation would be in the event handler and the validation is not the same as when the event was first introduced, loading your aggregate from the events might fail as the "old" data does not match to the current validation logic.