Skip to content

πŸš€ [NEW] Initialization and Clean-Up ScriptsΒ #60

@matejicko

Description

@matejicko

🫴 Proposal

Similarly to how the already implemented collection initialization script enables alternation of behavior of the collection, there should be possibility to have initialization script for each of its sub-collections/folders. This will simplify setup of more complex sub-collections/folders and make it more consistent than adding such a functionality to pre-request script of the first test case in the collection.

Same ideology should be applied for clean-up script, which will run in the end of (sub) collection execution.

The structure can look like this:

Image

✨ Motivation

Usually, when I want to do some setup before sub-collection run, I am forced to put it to the pre-request script of the first test-case. This is not the best solution, since the first test case can be re-ordered or completely removed. Similarly, if there is some clean-up, I am forced to put it to the post-response script of the last test case in such folder.

Having possibility to add the scripts with the roles of initialization and clean-up within each sub-collection/folder would increase modularization as well as cleaner separation of concerns.

πŸ”€ Alternatives

Naming convention of clean-up script can be different, alternatives that comes to my mind:

  1. finish.csx - not always it is necessary to clean something up, finish speaks about termination of some process
  2. teardown.csx - this aligns with testing frameworks wording and as well it is behind the init in the alphabet
  3. clean-up.csx - same word, but with hyphens

πŸ’‘ Possible implementation

Firstly, the structure exploration has to be modified. The final CollectionStructure object will probably contain references to sub-collections. CollectionStructure has to be enriched with the CleanUpScript property. And when speaking about the properties, it already possesses the environmental file, initialization script, so it would be maybe right to refactor it a little bit, since new file types can be added to the collection in the future.

βž• Additional context

Currently I am not aware of any additional context.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestproposalProposal of some functionality

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions