$j.gettype() can raise exception.
Maybe better:

$j | Should BeOfType System.Management.Automation.Job

Good catch 👍

Much better. Fixed.

The same:

Get-Job -id $j.id | Should BeOfType System.Management.Automation.Job

Fixed

It is seems we can remove $jobs.gettype().fullname | should be "System.Object[]" because next two statement make all needed checks well.

And again:

$job | Should BeOfType System.Management.Automation.Job

Fixed

Why pipe? It is confused with | Should Be.
We could use:
Remove-Job -Job $j -ErrorAction SilentlyContinue

Fixed

The same about pipes.

Fixed

Please replace -ea Stop with -ErrorAction Stop

Done

I don't like this idea - it can exhaust all CPU resources.
We could utilize something like get-content $TestDrive\jobs.txt -wait to get chunks in the job and send them to output.

Not sure I understand this. What would be adding data to jobs.txt while get-content waits? Would we use yet another background job for this?

Would injecting a short start-sleep (say .25 sec) mitigate the CPU usage concern?

Perhaps it is justified in these tests.
If no I would prefer synchronous and more deterministic tests.
0.25 is 250 ms so we could use file IO to be even faster.

1. The test write a test string to a file.
2. "start-job" job read (Get-Content -wait) the string and send to output
3. The test call Receive-Job (in loop up to 5 sec) to get the test string

I think @iSazonov means this:

BeforeAll {
    New-Item $TestDrive\jobs.txt -type File
    $j = Start-Job { get-content $TestDrive\jobs.txt -wait }
}

AfterAll {
    Get-Job | Remove-Job -Force
}

It "....." {
     Add-Content $TestDrive\job.txt -Value "Hello"
     Receive-Job $j | should be "Hello"
     Add-Content $TestDrive\job.txt -Value "World"
     Receive-Job $j | should be "World"
}

It "...." {
    Add-Content $TestDrive\job.txt -Value "Keep"
    Receive-Job $j -Keep | should be "Keep"
    Add-Content $TestDrive\job.txt -Value "Output"
    (Receive-Job $j) -Join "," | should be "Keep,Output"
}

I think this is better than the loop approach because 1) it's simpler to read and understand; 2) in case that receive-job really is broken, the loop might leave the test in a bad place.

@daxian-dbw Thanks! 👍
I believe we should put Receive-Job $j -Keep in waiting loop:

function WaitJobResult {
    $result = Receive-Job $j -Keep 
    $startTime = [Datetime]::Now
    while ($rerult -eq $null -or ([Datetime]::Now - $startTime) -lt 5)
    {
        Start-Sleep -Milliseconds  50
        $result = Receive-Job $j -Keep
    }
}

WaitJobResult | should be "Hello"

There seems to be some problem with comments on GitHub 😖

The while loop can be infinite 😕

Will it? $n will only be set to 5 or 10, and unless Receive-Job never returns enough output to meet those numbers the loop should end pretty quickly.

Here we test *-Job cmdlets so we cannot trust them.
We get results from Receive-Job. If Receive-Job will get the same results every call we shall get infinite loop.

Quite right. Changed to avoid endless loop.

Don't Remove-Job stop a job?

It does. Stop-Job removed.

lines 87 to 89 might not be necessary for this test as that behavior has already been exercised by the above test.

Removed those lines

This can be changed to $results = @(Receive-Job -Keep $job)

   It "Start-Job produces a job object" {
       $j.gettype().fullname | should be "System.Management.Automation.PSRemotingJob"
    }
  It "Start-Job can name the job" {
       $j = Start-Job -ScriptBlock {6 * 7} -Name "My Job"
       $j.Name | should be "My Job"
   }
  It "Get-Job retrieves a job object" {
       (Get-Job -id $j.id).gettype().fullname | should be "System.Management.Automation.PSRemotingJob"
   }

This may not strictly relevant, but for the 3 simple tests above, it seems too heavy to run start-job -scriptblock { 1 + 1 }, which essentially starts a process, before each test. Can we change the BeforeEach to

        BeforeEach {
            $j = start-job -scriptblock { 1 + 1 } -Name "My Job"
        }

and group those 3 tests into one?

We can certainly ad the -Name parameter in the BeforeEach block and merge the first two test together. Personally, I'd rather keep the Get-Job test separate.

That sounds good too.

Done

Thanks @jeffbi #Closed

doesn't the AfterEach remove the job? Do you need to start a job here?

why do you want to replace the original { start-sleep 15 } with this script block? None of the tests in this Context check the output of the job, so it's not necessary to write out anything. If you think 15 seconds is more than needed, maybe just { start-sleep 10 }?

That was done when I expected the Receive-Job tests to be in this Context block. Reverted back to Start-Sleep.

Typo.

It seems we should remove the line.

Darn. I thought I had. Removed now.

It seems we should remove the test because we already have a test for Wait-Job and have tests for Receive-Jobs too. (So much that the test contains errors)

This test is about receiving all the output. The other tests are about receiving partial output.
I'll remove this one if you prefer.

Next test implicitly check the same but it can be modified in future so we should leave the test with corrections:

        It "Receive-Job can retrieve job results" {
            Wait-Job -Timeout 10 -id $j.id | Should Not BeNullOrEmpty
            receive-job -id $j.id | Should be 2
        }

Usually we explicitly use a string in quotes "Completed".

It makes no sense to make 'Should Be' for every array member.
Maybe better:

checkContent $array | Should Be $true

            function checkContent($array)
            {
                for ($i=1; $i -lt $array.Count; $i++)
                {
                    if ( $array[$i] -ne ($array[$i-1] + 1) ) { return $false}
                }
                return $true
            }

Changed.

Both checkContent should be removed because this has already been checked in the previous test.

And it makes no sense to make 'Should Be' for every array member. We could use Compare-Object here.

Now using Compare-Object to compare the beginning of the second Receive-Job with the results of the first, and a single check to ensure that the second Receive-Job didn't miss any data after the first.

The same about string quotes .

Please remove the debug code.

if ($count -eq 10000)

It should be 1000 instead, otherwise the timeout would be 50 minutes 😄

Yikes! Fixed.

To be accurate, we should use the Perser style:

{ throw "qwerty" } | Should Not Throw

Comparing

PS:89> describe "abc" {
>>       it "def" { throw 'Receive-Job behaves suspiciously: Cannot receive 5 results in 5 minutes.' }
>>       it "hgi" { $true | Should be $true }
>>     }
Describing abc
 [-] def 25ms
   Receive-Job behaves suspiciously: Cannot receive 5 results in 5 minutes.
   at line: 2 in
 [+] hgi 15ms

with

PS:90> describe "abc" {
>>       it "def" { { throw 'Receive-Job behaves suspiciously: Cannot receive 5 results in 5 minutes.' } | Should Not Th
row }
>>       it "hgi" { $true | Should be $true }
>>     }
Describing abc
 [-] def 32ms
   Expected: the expression not to throw an exception. Message was {Receive-Job behaves suspiciously: Cannot receive 5 results in 5 minutes.}
       from line:2 char:20
       + ... t "def" { { throw 'Receive-Job behaves suspiciously: Cannot receive 5 ...
       +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   at line: 2 in
   2:       it "def" { { throw 'Receive-Job behaves suspiciously: Cannot receive 5 results in 5 minutes.' } | Should Not Throw }
 [+] hgi 17ms

The first one is more readable. And in this case we throw the exception on purpose to fail the test case, so "{ throw "qwerty" } | Should Not Throw" feels like doing extra work for the same purpose. Maybe we can just keep it as is?

Yes, we should keep. (This exception should raise never. So a performance should not be taken into account.)
The idea was that all the results of the tests have to be caught by Should that Pester normally logs the results. But I check "Pester.xml" and see that the original throw is logged well.
Closed.

System.Management.Automation.Job is string so it would be safer to use quotation marks:

$j | Should BeOfType "System.Management.Automation.Job"

Below too.

Added quotes around type names

What about $result2[0..-1] ?

This is to compare the whole of $result1 with the first n elements of $result2, where n is the length of $result1. Did the second Receive-Job return all of the data that the first one did?

Then it checks for any missing data by seeing if the element immediately following the first n in $result2 is the next number in sequence.

Yes, Closed.
Maybe only use -SyncWindow 0.

It seems we agreed to leave the test with improvments.

Test added back, with improvements

Since you don't do "| Should Be" in CheckContent now, the result from this function should be checked.

Told myself to do it, missed it. Thanks for catching.

With -SyncWindow 0, Compare-Object compares 2 lists in order. Example:

PS> $a = 1,2,3,4
PS> $b = 2,3,4,1
PS> $c = 1,2,3,4
PS> Compare-Object -ReferenceObject $a -DifferenceObject $b
PS> Compare-Object -ReferenceObject $a -DifferenceObject $b -SyncWindow 0

InputObject SideIndicator
----------- -------------
          2 =>
          1 <=
          3 =>
          2 <=
          4 =>
          3 <=
          1 =>
          4 <=

PS> Compare-Object -ReferenceObject $a -DifferenceObject $c -SyncWindow 0
PS>

You can add this parameter if you want to compare them in order.

Please swap BeforeEach and AfterEach.

Done

The test don't use $j so we should move it in separate Context block without creating a job in BeforeEach.

Done