1466197 - Redo beetmoverscript testing infrastructure

Status: RESOLVED DUPLICATE of bug 1672691

(Release Engineering :: Release Automation, enhancement, P2)

Description

[Mihai Tabara [:mtabara]⌚️GMT]

So that we can safely make changes to templates or other functionality pieces that are not yet covered by automation. Even though we're planning on moving them in-tree in bug 1462393, there's still value in adding them.

A good example of this lies within shipitscript[1].

[1]: https://github.com/mozilla-releng/shipitscript/blob/master/shipitscript/test/integration/test_integration_script.py

Comment 1

[Mihai Tabara [:mtabara]⌚️GMT]

With declarative artifacts slowly rolling out, it's time to think about the future of beetmoverscript testing.
Currently the issues are:

* we don't have integration tests at all. We've been bitten several times here as we only test various functionality behaviors within unit tests and more often than not we get breakage in BR jobs after a certain PR is merged. 
* the existing testing infrastructure could be improved to be nicer and easier to read, and more importantly, easier to add tests
* ideal goal here is to make sure that for each change of code lines in beetmoverscript, we have integration tests to cover each and single type of task for beetmover.

This will catch errors early and enhance devlopment. It'll also improve readability and enforce more tests with each line of code.

With declarative artifacts rolling-out completely, there's lots of clutter we can trim from beetmoverscript.

I aim to work on this as a personal project, side from work.

Comment 2

[Mihai Tabara [:mtabara]⌚️GMT]

Found in triaging. Not actively working on this, returning to the pool.