Should illegal execution contextes be allowed?

[teppolainio]

On SDK documentation it is said that for example with Delete message Target of InputParameters is EntityReference. I've seen on few occasions developers forgetting this when implementing unit tests and they've used Entity type instead of EntityReference.

Should this kind of errors generally be caught by fake-xrm-easy and raised as exceptions when test is run?

This particular case for example is pretty clear misunderstanding by developer about how platform execution pipeline works. Most likely one has just forgotten but nevertheless this makes developer to write code which doesn't work on actual environment and this is pretty easy to catch.

[jordimontana82]

Hi @teppolainio

That's great feedback, thanks Teppo.

Yes, I think it would be beneficial to raise exceptions like that, specially for developers who are new to the platform.

Will you fancy a PR?

[jordimontana82]

We could possibly add a new method to check illegal execution contexts at the end of this method

[teppolainio]

I'm somewhat busy now but I think I can have time to start with a PR within a month.

What I've been thinking a bit is to have execution context validation done by message executors because valid or invalid execution context pretty much depends from message being executed. What do you think?

[jordimontana82]

@teppolainio Yes, I think adding a new method like "bool IsValid()" on the IFakeMessageExecutor interface would be nice, and we could default it to true for existing messages so it doesn't cause regressions, and slowly include these validations.

[jordimontana82]

Something like

public bool IsValid(OrganizationRequest request) {

}

And we update the main entry point in the .Execute mock in XrmFakedContext class to call .IsValid after .CanExecute and before .Execute