From Excel to the PS1 file

[epernst]

I think that the TestScriptor is a great way to quickly get from a BDD/Gerkin test scenarios to a empty test codeunit ready to write our tests. At least if you are a developer who understands Powershell.
Even if the Powershell file does not contain a lot of "code", then it's enough to make consultant, testers and especially end user see black, if you ask them write their test scenarios like this. At least that's been my experience.

Now our developers manually copy/paste the GWT scenarios from the test section of our Azure DevOps work item directly into a test codeunit (created with a snippet). Copy/pasting it into ATDD.TestScriptor would maybe speed it up a little, but they still prefer to do it directly just to avoid PowerShell (I don't know why most BC developers are so afraid of Powershell).

If this scriptor should become mind-blowing useful, then we had an even simpler way to write the scenarios. Everybody knows how to use Excel (and nobody I know are afraid of Excel), but could be an even simpler file for that matter. As long as it can still be attached to the work item or uploaded to Teams.

The ability to sync (thanks to Marton) the test codeunits back to the file again, is also something we would be using, as it would allow us to keep our overall test plan up-to-date continually. Something like linking the test results from DevOps back to our test plan would be possible, or even linking it together with flaky-test management.

I know this is not a normal "Issue" as such, more a comment/discussion post, as I see a great potential for ATDD.TestScriptor, it's just not so easy to "sell" it right now.

[lvanvugt]

Hi Erik, thanx for the feedback.
When I started off this project I began with an Excel sheet as you know. The one share on the GutHub project that goes with my book: https://github.com/PacktPublishing/Hands-on-Automated-Testing-in-Microsoft-Dynamics
Working with Jan on this PowerShell Module we came to the current version with the PowerShell "interface" as in the end making use of aliases it's not really PowerShell.
As you have seen we are discussing the next version, which tends to go a somewhat different road and we will take your feedback into account.
Having said that, it's such a shame that developers have this fear of PowerShell. They are actually being short on them selves. Especially if you have been working with the current version for some time.

[jhoek]

Fully agree with Luc (as usual ;-)). This is actually in response to #24, #25 and #26: the initial plan was to have a domain-specific language for defining test "skeletons", after which a one-way conversion could turn them into AL codeunits (and potentially other formats - e.g. a human-readable MarkDown document). It turns out more flexibility is required in day-to-day use.

I'm not too keen on using Excel for this. It's so flexible that users could easily and inadvertently break the structure of the tests. We need something that is less fragile and more light-weight.

Also, for full round-trip fidelity, the new format should include any code that was already written in the helper methods by the developer. The only meaningful round-trippable format that I can think of right now would be - surprise! - the AL itself. The only thing our tool should do is offer a high-level, functionally oriented view on the existing test-code.

If you're saying functional experts tend to scare away from PowerShell, I'm sure something similar is true for VS Code. My current thinking is something like a stand-alone, possibly Electron-based executable that offers a high-level tree-based representation of your test codeunit, and has menu options to add/edit/remove elements such as features and scenarios. Behind the scenes, this should modify your existing AL file, just like VS Code does.

Please let me know if you agree, or if there are any flaws in my reasoning. :-)

[lvanvugt]

Because of this issue and #24 we have decided to put effort in creating a VSCode extension that will replace our PowerShell module and allow us to add more feature like the one on this issue.
Therefor we close this issue.