Added Module Link URI Tests

[gerane]

• If a uri is provided it will use Invoke-WebRequest and expect a 200 response code.
• I have found 1 link so far that gave a false positive. The site was blocking the request via IWR but allowed via browser.
• I have found this Helpful in what I have worked on, but maybe there could be instances where a URI is known to be non functioning and that is expected.
• There is also the scenario of Tests being ran offline. So, this may be something that is given as an option.

[gerane]

I know this might not totally work as is. I am sure there are cases where Tests need to be ran offline.

One thing I have been thinking about, was adding a little config file. Since not everyone uses the same folder structure, they often will need to hardcode the ModuleName or Path into the script.

If you have a little config file that let you set Module Name, Paths, and options to exclude certain tests, I think it will answer many of those issue. Just drop it into the same directory as the Test file.

[juneb]

Just a few suggestions.

-- Use a Describe block instead of a context blog. That lets you add a tag that users can use to exclude the test.
e.g. Describe "$CommandName : URL links should be valid" -Tag OnlineOnly { ... }

-- To exclude empty links (no need for extra if Link):
$Links = $help.relatedLinks.navigationLink.uri | Where-Object {$_ -ne ''}

e.g.
Describe "$CommandName : URL links should be valid" -Tag OnlineOnly {
$Links = $help.relatedLinks.navigationLink.uri | Where-Object {$_ -ne ''}

    foreach ($Link in $Links)
    {
        # Uri returns OK. Doesn't verify content
        It "[$Link] has 200 status code" {
            $Results = Invoke-WebRequest -Uri $Link -UseBasicParsing
            $Results.StatusCode | Should Be '200'
        }
    }
}

[gerane]

Awesome, I totally forgot about tags. Both suggestions are great ideas.

What are your thoughts on handling slightly different module layouts? The more projects I contribute to, the more I am noticing that many do not follow the standard layout. I have started using a slightly altered layout that Warren F uses. It just kind of naturally makes sense in some scenarios. It makes deploying the module much easier.

It has the module in another subdirectory. $ModuleName$ModuleName\

Posh-Teamviewer
    - Posh-Teamviewer
        - Module Folders and Scripts here.
    - Tests
        - Tests here.

I have also been seeing more of a need to break tests up into subdirectories.

Posh-Teamviewer
    - Posh-Teamviewer
        - Module Folders and Scripts here.
    - Tests
        - SubCategory
            - SubCategory Tests go here
        - SubCategory
            - SubCategory Tests go here
        - SubCategory
            - SubCategory Tests go here

Then I have seen many others that handle it with other types of Sub folder for the module.

Posh-Teamviewer
    - Release
        - Posh-Teamviewer
            - Module Folders and Scripts here.
    - Tests
        - Tests here.

I have just been trying to think of an intelligent way to handle different module layout scenarios without having to worry about editing the scripts themselves while still being able to drop in a Tests folder and let Pester handle execution.

[gerane]

Hmm, what if you did this.

ModuleName.Help.Tests.ps1.

The Test could the extract the ModuleName from the Test filename.

EDIT: Hmm, this might be an option as well.

C:\PS>Invoke-Pester -Script @{ Parameters = @{ ModuleName = 'Posh-Teamviewer'; RequiredVersion = '1.0.1' } }

[gerane]

I moved these to a Describe block and added a "Links" Tag. I can change the tag to whatever sounds best to you.

[gerane]

Ok, I am going to have to alter this. This part is not working properly

$Links = $help.relatedLinks.navigationLink.uri | Where-Object {$_ -ne ''}

It is still testing links that are empty

[gerane]

Ok, seems to be working properly now. I added a $null check.

$Links = $help.relatedLinks.navigationLink.uri | Where-Object { ($_ -ne '') -AND ($_ -ne $Null) }