How to test an action in a test codeunit ?

Hey guys,

I have created an action in a page extensions and now I want to test its functionality.

trigger OnAction()
                var
                    Resource: Record Resource;
                    Handled: Boolean;
                begin
                    OnBeforePrint(Handled);
                    if not handled then begin
                        Resource.SetRange("No.", "No.");
                        ResourceLabel.SetTableView(Item);
                        ResourceLabel.RunModal();
                    end;
                end;

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 :wink: 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:

ItemCard.HasFinished.Activate();

ItemCard.NotYetFinished.Activate();

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:

  1. What is the TestField method Activate() actually doing? And when would it error?
    https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/testfield/testfield-activate-method

  2. What should the TestField method Invoke() actually doing? I am always getting the error: The Invoke method is not supported.
    https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/testfield/testfield-invoke-method

  3. If a field is not editable or not enabled what should the methods Value() and SetValue() actually do?
    I would expect them to fails as a user would not be able the change the value of a disabled/non-editable field. But suing these methods in my tests they do not fail. So how to verify that such a field indeed is not editable?

Have posed these questions to MS, so to be continued.

Answers form MS:

  1. It should activate the control, similar to user clicking the control itself / putting the focus. Only exception that can be thrown is if the form is not active (I do not know when this can happen)- so I would say no errors :slight_smile:
  2. Invoke should invoke the default action on the control. It is not supported at all, we are throwing the exception, so it is a feature that has not been implemented. Should not be used
  3. You can query the Editable property on the testfield. If you want to know whether your code is setting Editable correctly this is what you should do.

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.