Ideas of using TODO in pester tests.

[Peter Taylor]

Hi there, can I ask if anyone has suggestions or recommended practices of using TODO statements in pester tests that helps me track what bits I need to work on while testing code so I know what to do as I go along.
Thanks and kind regards,
Peter.

[Chris Dent]

Use Tags? You can include / exclude those when invoking pester so it'll make tracking such things relatively easy.

Chris

--
You received this message because you are subscribed to the Google Groups "Pester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pester+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Taylor]

Thanks, got some examples or a link so I could see?

[Chris Dent]

The Tag applies to Describe which may work. Another method is to use the Pending switch of It. Examples of everything I could think of follows. The code is just to have "something" for the tests to do.

On reflection I suspect Pending might be the better choice, but it depends a little how broad you need it to be.

Is this what you had in mind?

function Test-Prime {
    [CmdletBinding()]
    param(
        [Parameter(ValueFromPipeline = $true)]
        [Int]$Value,

        [Switch]$AsValue
    )

    begin {
        $isFalse = $false
        $isTrue = $true
    }

    process {
        if ($AsValue) {
            $isFalse = $null
            $isTrue = $Value
        }

        if ($Value -lt 2) {
            return $isFalse
        }
        if (($Value -band 1) -eq 0) {
            if ($Value -eq 2) {
                return $isTrue
            } else {
                return $isFalse
            }
        } else {
            for ($i = 3; ($i * $i) -le $Value; $i += 2) {
                if ($Value % $i -eq 0) {
                    return $isFalse
                }
            }
            return $isTrue
        }
    }
}

Describe Test-Prime {
    It 'Returns false when passed a number less than 2' {
        Test-Prime 1 | Should Be $false
        Test-Prime 0 | Should Be $false
        Test-Prime -1 | Should Be $false
        Test-Prime -2 | Should Be $false
    }

    It 'Returns true when 2 is passed' {
        Test-Prime 2 | Should Be $true
    }

    # Mark It as pending, perhaps because the test case was
    # nothing more than a quick note
    It 'Returns true when a larger prime is passed' -Pending {
        Test-Prime 25 | Should Be $false
    }

    # Mark It with skip, it'll show, but it won't count without
    # strict
    It 'Returns false when an even number is passed' -Skip {
        Test-Prime 100 | Should Be $false
    }

    # Or don't fill in the body (similar to Pending, same output)
    It 'Does something else I meant to talk about' {

    }
}
# Tag Describe with TODO
Describe Test-Prime -Tag TODO {
    It 'Returns the original number when AsValue is used' {
        Test-Prime 7 -AsValue | Should Be 7
    }
}

# When invoking pester

Invoke-Pester -ExcludeTag TODO

On 27 January 2017 at 20:00, 'Peter Taylor' via Pester <pes...@googlegroups.com> wrote:

Thanks, got some examples or a link so I could see?

[Peter Taylor]

Hi Chris,
I wouldn't know where to start so thank you for the head start for me in adapting this approach the first time round.
Just reading the code you provided gives me the impression that:
a. TODO works well for proving certain test or use cases as you did in checking prime numbers when using describe (in scope of requirements). This has given me food for thought this way where it's expected the complete use cases are listed.
b. The broad idea from my point of view is bits of TODO in the script or module at some stage is a means to see my work in progress overall.

Kind regards,
Peter.

[Chris Dent]

I think that can work to an extent, but it's difficult to track in the body of your code (at least in my opinion).

You'd be better tracking those on a Kanban, or as an issue in Github, or something outside of the code base. I think that helps when you have more than one person working on a thing.

[Peter Taylor]

No worries, I can see where the complexity makes this process tricky later in the lifecycle.
Hmm, I see how I go with this for a while and if this rears an ugly head I'll resort exporting the tags/markers or todo list into a third party software for better management/overview. Thanks again Chris.

[Peter Taylor]

Just a quick touch base to my thread here to say I am really, really happy that "-Pending" rather than "-Skip" suggests at the end of IT test cases does the trick for me.
This is good so my habit of doing a brain dump of the idea (test cases) first and then I physically catch up afterward updating the code helps.

As the output of Appveyor tells me.
Describing CodeAudit
[?] Always have functions documented 32ms
[?] Prove that this change works on the desktop as I do here testing in Appveyor 6ms
[?] Obtain the Github release location via localpassed variable 4ms
[?] Fetch the file from Github release location into Testdrive 2ms
[?] Start processing the release file opening up the zip file 2ms
Context Strict mode
[+] Get-SomeInt should return int 27ms

Cheers,
Peter.