2

We are automating the testing on an Web ERP solution (Dynamics) through a tool (RSAT, which uses selenium) provided by the developer of the ERP (Microsoft).

The RSAT has a list of instructions to do some actions on the pages and it takes the values to use from an excel file. The RSAT can be used with command lines.

So at first we started using a PowerShell script and Azure DevOps to launch the automated tests right after the code packages has been deployed to the testing environment.

It was a few dozen lines long and it was fine.

Then we started switching the values in the parameter excel file with other values to cover more tests values with the same test case.

It added a few hundred lines to the script.

  • Then we generated a file in which we compiled all the results of the tests,
  • We added some logs,
  • We sent the result file by mail,
  • We queried and rolled back the database right after finishing the tests,

Well, my problem is that PowerShell script is growing a lot (we actually have multiple scripts now with script 1 calling script 2 when it ends and chaining all the actions) and we still have many features and ideas to add.

My question is: at which point should we say

stop, PowerShell is not meant to do this, for the sake of maintainability and stability we should switch to [Python/C#/...]

(Maybe I'm totally wrong and using multiples chained PowerShell scripts is actually good practice, especially when you use Azure DevOps)

Improve this question
3
  • 1
    see How do I explain ${something} to ${someone}?
    – gnat
    Jan 28, 2020 at 12:10
  • Thanks, I'll cut my question to : should we do that ? then
    – Maxime
    Jan 28, 2020 at 12:12
  • I've done this. It even included a WPF GUI (!). But it was a very small application (well, compared to anything else we do here; but it was still a lot of code). Some of its functionality was loosely related to what you're doing. You should take a step back and see if you've followed good principles while adding to it and, if not, whether fixing that (refactoring) is better than rewriting functioning code in a different language "just because".
    – MetalMikester
    Jan 28, 2020 at 13:00

2 Answers 2

Reset to default
3

Each line of code you write needs to be tested and maintained. If you get intermittent build failures due to defects in the scripts, then the PowerShell scripts are getting difficult to test. If extending the PowerShell script is becoming difficult, then maintainability is becoming an issue. When deciding to go from a "simple" scripting language to something else I usually cite testing and extensibility is the main reasons for doing so, but only after refactoring the scripts to make sure I'm not just moving poorly written code from one language to another.

A (Power)Shell script should:

  • Be composable. It should be callable and make sense on its own, and it should be easy to call within other scripts. In the object-oriented world this would be the Single Responsiblity Principal (a shell script should only have one reason to change).

  • Have a descriptive name. If you can't come up with a good name, then bullet point #1 above might apply, or this script should be a well named function inside another script.

  • Have a well documented interface. For PowerShell this means comment-based help.

It is common to write scripts as a harness for building, deploying and testing an application, and what you are describing doesn't sound particularly hard. You need to understand what a tool like PowerShell gives you (argument parsing, looser syntax rules, etc...) and determine if those advantages are worth giving up in order to gain the greater testability and extensibility that a more fully featured language gives you.

Improve this answer
1
  • Loose syntax rules are good for interactive use, but for scripting, generally you want to limit to using stricter, unambiguous syntaxes.
    – Lie Ryan
    Jan 29, 2020 at 3:43
3

PowerShell is a script language. It is designed to rig-up function blocks created using programming languages. The pitfall to application programmers when they start using PowerShell is that they approach it as a 3rd generation programming language. They take their experience from C/Java/Pascal and try to map that to the PowerShell environment. This soon becomes a problem because it does not map very well. PowerShell behaves in unexpected ways to them. Everything is pushed forward to some output channel. This is not how software developers think.

PowerShell is great for automating tasks that would otherwise be performed by humans in sequence. You have some input and you expect some output. It is not that great as an interactive tool like a GUI application where you have a lot of state that the used can play with before calling it done. PowerShell is .NET based and can interact with the .NET framework, basically allowing you to do anything you should not do.

So no, I would not encourage you to use PowerShell for more than one-shot commands that have a clear and dedicated purpose. I used it a lot myself, am still using it on a daily basis, and I ran into all the problems just described. The combination of PowerShell and any "normal" programming language in a Windows environment is pretty powerful. Just be aware of what it was meant to be used for and stick to that.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.