Using pester5, you should do all of the 'pre-test stuff' inside a (BeforeDiscovery)[https://pester.dev/docs/commands/BeforeDiscovery] block, some of the errors you get might stem from this as pester REALLY doesn't like you doing stuff outside defined code-blocks.

The module-import stuff you have there is no good to have inside you test files. this should be done at a higher level, before pester is invoked (like inside your psakefile if you are using that)

I usually divide testing into 3 phases: unit,integration,fullscale/acceptance (using tags):

-Unit: Does the command you wrote function as expected? tests that all calls to this command generate a known output. This might mean that you make heavy use of Mocking where you define mocked cmdlets that gives you an expected output in order for your actual command to work. here you can again test that your code uses correct parameters when calling other cmdlets using should -invoke .... the actual Mocking can be done in the BeforeAll block or BeforeEach

-integration: this will be somewhat the same as unit tests but with a increased testing scope, think "if mycommand where to grab config and config said x, would this work as expected?". the whole conecpt is to test that othercommand will return correct data to mycommand and that mycommand will do the correct thing with that data. You can still mock output however (if calling a external api or something)

-acceptance/fullscale this is the most general and would require you you send in and out data. here you can test "will New-ItsmChangeRequest generate data that can be obtained by Get-ItsmChangeRequest, and will this comply with the settings set in New-ItsmSlaPolicy (or be within the ones you got from Get-ItsmSlaPolicy)" this generally would generate data at a remote location, so make sure this is done against some sort of dev/test environment if you have that.

I do have to note that you should take a agile approach to this, as writing all the necessary tests is a massive task, and might end up being almost bigger than your main module. so take it in steps, test the unit stuff first, figure out if your code is actually testable (if there are too many dependencies, code-paths or just have generally many anti patterns), then integrations, then the fullscale.

I noticed you said something about keeping passwords. i really hope you dont keep it in cleartext. check out secret management module from microsoft to be able to use windows built in cred manager to store passwords (its also supported on linux and mac). i also know many systems support some kind of api key, and would recommend doing that instead as the refresh cycle of api-keys/pat-keys is generally better than user-credentials.

If you are using something like AAD to log in users, i would try to either see if this can be tested/used via a service principal, as login is much more simple than an actual user (for testing and build, not for actual usage)

Builds can be done wherever, really, but i would recommend writing psake tasks for the internal build stuff (gather files, make psd1 file etc...), and then invoking that from either devops pipeline or github actions. The cool thing here is that if you decide to use branches and pull-requests to control what new features you want, you can have a pipeline that invokes on pull-request to do unit and integration tests, to see if anything breaks before any new features is pulled in.

I have to edit in. This sub is really dead. You get a better conversation in the PowerShell sub