I have created an action in a page extensions and now I want to test its functionality.
Resource: Record Resource;
if not handled then begin
Do you have an idea?
Do I have to test all actions, which I have created for my extension?
Basically your extension tests have to show that your extensions is doing what it should do. From that the answer to your question is: yes. You can test actions using a test page object. But you could also embed the implementation of your action (and I reckon this to be best practice) in a method on the page (or preferably in a codeunit). Then you can test the method separate from a UI.
Thank you ;) and do you know how I can proof, whether two bool fields are set to be true? Did by the user?
By the user? In automated tests? Maybe give me some more context on what action(s) lead(s) to you wanting to test this.
I have a page and on that page, there are two bool fields. It is only possible to activate one of this fields. So now I want to test, whether I can activate in an automated test both fields at the same time.
I guess you mean you want to check that you actually cannot do that, right?
Did you have a look at all field control methods on a testpage: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/testfield/testfield-data-type?
Yes, it should not be possible to me.
I know that page, but it does not help me.
I am doing this:
And then there should come an error or so.
Dived somewhat more in this as I haven't been using TestPages yet in this way.
And not sure if I do understand it all:
Have posed these questions to MS, so to be continued.
Answers form MS:
MS reply on 3 did was not a complete answer so I posed: If a field (control) is not editable SetValue/Value calls should, IMHO, also fail.
MS answered: The quick answer is "what it currently does", because that is what it has done for the last 8 years:-) I must be honest to say that I don't remember what design discussions we had around it back then. There may be tests already written that utilizes this functionality, that will break if we change it now. Arguments can probably be made for both and the risk of breaking some existing tests out there will probably outweigh potential more correctness from a purity perspective.