In future phases, this restriction will be lifted. We're starting small and will continue to add features as time goes on. Are the docs not clear? Is there a missing feature that is keeping you from doing the tests you want to do? We want to know! Everything should work and documentation should be in place but we really want feedback. In phase 1, all tasks will be run on build for that rpm.Īll folks putting tasks into dist-git during phase 1 should consider themselves "early adopters". The most straight-forward way to do this is to store the tests with the "code" which, in this case is the files in the rpms namespace in dist-git. See the documentation.įor phase 1, the idea is to start getting tasks and tests into place In general, the best place to start is with the Taskotron devs who can be most easily found in the following ways:įor now, all tasks will need to be written for libtaskotron. There is a strong push for more CI-like features for testing Fedora but in order to support that, we need a way for contributors to submit tests that will scale with the number of components we have and require minimal human intervention. Any changes to this will be announced on devel-announce before any breaking changes are put into place.
This is not yet final thing but it is what we're starting with. This page describes the current state of task storage in dist-git repositories.
#Pester wiki update#
To update all of the It statements in one shot, we’ll use a PowerShell default parameter. Just like it sounds, if Skip is $true, the test is passed over. If $IsWindows evaluates to false, we’re going to update the Skip parameter of the It statement. In PowerShell 6 there are are couple of new variables that we can use to determine what platform we’re on, $IsWindows, $IsLinux and $IsOSX.
Since Test-Connection is only available on Windows, we want to skip these tests on all other platforms. Before we go into those, lets take a look at the completed describe block.īeforeAll Skipping Tests in Mass - BeforeAll and AfterAll Most of the tests are straight forward but there’s some neat tricks and best practices the PowerShell team requires of its test. The example used in this article is from my most recent commit, basic Pester tests for the Test-Connection cmdlet. The PowerShell Team has done a good job of utilizing Pester and forcing all new commits to come with corresponding test but there’s still gaps. One of the most important and often most overlooked areas is test coverage.
Like I said, there’s still a ton of work to be done in PowerShell.
Go to the PowerShell Github Page and start contributing! Aren’t that good at C#? Add some documentation or a Pester test. I understand that putting yourself out there can be scary but everyone is incredibly friendly and its a great place to get constructive feedback. Its a direct way to interact with the team, see what features are being worked on and actually make a difference. A hobby of my mine is to peruse the PowerShell Github page for open issues and pull requests.
0 kommentar(er)
