Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Dead discussion but the concerns are very much alive. </p> <p>The one thing I see missing from the discussion of the usefulness of unit testing PS given its intended use involves modules in an enterprise system. Imagine an enterprise setting with a central repository for common network-/file-level tasks implemented in PS. In this setting, you have a small number of developers and network specialists all of which have slightly overlapping duties. A developer creates a module encapsulating business logic and its usefulness is immediately acknowledged such that in no time, others jump in and incorporate the module in their own efforts. The module is included in anything from one-off interactive scripts to medium-sized client applications; While some might not agree on the use cases for a shell-scripting language, evolution is a constant in this field. </p> <p>In this scenario, I believe there's value in defining a set of "contracts" for these common modules to follow. If knowledge-sharing is integral to the organization then it's possible more than one person would be modifying these modules. Having unit tests validate the integrity of the modules would go a long way towards maintaining order and minimizing chaos thus sustaining (perhaps increasing) the value of the modules themselves.</p> <p>As to a preferred approach, I've yet to adopt one. PS brings to mind a fluid/dynamic/agile substance. Containing it within a rigid structure such as what I've seen with TDD feels unnatural. However, given the scenario above, this goal can't be ignored. Nevermind, I'm torn, sorry to waste your time. Thank you for reading.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload