Use Case: Updating Given-When-Then

[lvanvugt]

The following flowchart shows the use case:

Exceptions

• Non-alpabathic or non-numerical characters should not be ported to helper function names (see also Use Case: Adding Given-When-Then #27)
• Given/When/Then description should not have unlimited length as AL function names have a max length of 120 characters
  • I suggest to build logic that checks allowed length in Given/When/Then description based on text with "to be removed" non-alpabathic or non-numerical characters (see also Use Case: Adding Given-When-Then #27)
• A helper-Function will only be renamed if it matched the old value of the given-when-then-statement.

Settings

• Make setting possible that user can set max length to Given/When/Then description himself (see also Use Case: Adding Given-When-Then #27)
• Standard each newly created helper should get an error statement assigned with test " is not yet implemented"; user should be able to turn this of with a setting (see also Use Case: Adding Given-When-Then #27)
• A setting is needed to provide for each helper function type, i.e. Given, When or Then, a syntax allowing, for example, to add a standard term (verb) to the name. (see also Use Case: Adding Given-When-Then #27)
  • Example were Verify is added as prefix to THEN helper function (see also behavior of the ATDD.TestScriptor PowerShell module) (see also Use Case: Adding Given-When-Then #27)

THEN clause: Warehouse shipment line is deleted
function name:  VerifyWarehouseShipmentLineIsDeleted();

Notes

• Addition of new helper function is also to be found on use case Use Case: Adding Given-When-Then #27

[DavidFeldhoff]

Adding to the exceptions:
A helper-Function will only be renamed if it matched the old value of the given-when-then-statement.

[lvanvugt]

Adding to the exceptions:
A helper-Function will only be renamed if it matched the old value of the given-when-then-statement.

Added to main description.

[DavidFeldhoff]

@lvanvugt with the latest changes on the "AddingGivenWhenThen"-branch the rename-part is ready to test. Please give me feedback, if something's missing.
I don't know yet what to do in the following cases:

// [GIVEN] Manually created warehouse shipment from released sales order with one line with require shipment location
        WarehouseShipmentNo := CreateManuallyCreatedWarehouseShipmentFromReleasedSalesOrderWithOneLineWithRequireShipmentLocation(LocationCode);

Currently I update the procedure call to a renamed one and let the return value and the passing of the parameter untouched. But the newly created procedure with the updated name does not have a parameter or a return value, so that there's a compiler error. But maybe if don't assign the variable on return anymore I'll have a similar - maybe even worse - problem as probably everything is compilable, but the tests will fail as the variable which was assigned on return previously isn't assigned anymore yet which could be tricky to find out.
It would be possible to add the return variable and the parameter by using the AL CodeActions extension, but then we'd have a dependency.. I'll leave that decision up to you.

[DavidFeldhoff]

@lvanvugt I found a case which is not defined yet:
We're in the upper right corner in the flow chart. Given helper functino is called multiple times? No -> New helper function already exists? -> What to do? I can't rename the old one as there are two functions wit the same naming and parameters then. Should I switch to the new one then and ask the user if the old one should be deleted?

[lvanvugt]

@DavidFeldhoff great catch. I would say, leave the old one. Would that make sense?

[DavidFeldhoff]

So we would change the procedure call to use the existing one and leave the old procedure as it is (which won't have any references then)?

Or should we just throw an error in this rare case that the user should solve it on his own as it could be that there's no right or wrong

[lvanvugt]

OK, misunderstood it first. Your latter suggestion makes sense. Let's do that.

Or should we just throw an error in this rare case that the user should solve it on his own as it could be that there's no right or wrong

[lvanvugt]

Retest, but two news bugs appear (see above).

Update 20201029
One to go: #68

[lvanvugt]

Retest, but new bug appears (see above).

Update 20201121
One to go: #79

[lvanvugt]

As #79 was retested and found OK this Use Case is ready