xWebsite: Compare LogTruncateSize parameter correctly

[nickgw]

xWebsite attempts to compare the passed $LogTruncateSize to (essentially) (Get-Website -Name $name).logFile.LogTruncateSize except, the parameter is truncatesize. This causes the comparison to always fail.

Fixes #380

---

This change is 

[msftclas]

All CLA requirements met.

[johlju]

Could you please look why the tests are failing?

[nickgw]

Looks like there was something else going on at the same time:
The process cannot access the file 'C:\windows\system32\inetsrv\config\applicationHost.config' because it is being used by another process.

I'm not sure how to trigger the appveyor build again.

[johlju]

Ah some timing issue, think I’ve seen that before. Closing the PR and directly reopening the existing PR again will kick off the tests again.

[codecov-io]

Codecov Report

Merging #381 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev     #381   +/-   ##
=======================================
  Coverage   90.44%   90.44%           
=======================================
  Files          17       17           
  Lines        2450     2450           
=======================================
  Hits         2216     2216           
  Misses        234      234

Impacted Files	Coverage Δ
DSCResources/MSFT_xWebsite/MSFT_xWebsite.psm1	95.63% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a07d02c...e739797. Read the comment docs.

[johlju]

Reviewed 2 of 2 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @nickgw)

a discussion (no related file):
Could you please look at the unit tests for this resource and figure out why (unless you already know) the unit tests passed with the wrong parameter name LogTruncateSize? We need to add a regression test that tests this change.

---

[nickgw]

I believe it is because the unit tests always check for failure scenarios but never successful scenarios. If I'm reading the tests right:

L269 test that they match, calling the right parameter names (LogTruncateSize for passed parameter and truncatesize for website parameter),

L681 test for failure when the truncatesize is different, and

L777 tests for failure when LogTruncateSize is larger than truncatesize.

L1524 isn't testing for comparison between the two (though I'm not the best with Pester).

If there was a test that the given LogTruncateSize matches truncatesize looking for a True, this would have been caught.

[johlju]

When looking at the lines you provided, it seems that the unit test was mocking this correctly, so the unit tests always tests the correct property.

https://github.com/PowerShell/xWebAdministration/blob/a07d02c295f49efd5a608f0915a7dfdf19d6da2b/Tests/Unit/MSFT_xWebsite.Tests.ps1#L102-L122

https://github.com/PowerShell/xWebAdministration/blob/a07d02c295f49efd5a608f0915a7dfdf19d6da2b/Tests/Unit/MSFT_xWebsite.Tests.ps1#L665

We should test this property in the integration test, where it would have been caught, since there Get-WebSite is not mocked.

[johlju]

No I take that back. This should have been caught in the unit tests. Something is off with the unit test. It mocked the return value as, for example, truncateSize = '1048576' , and that could never have been returned, since when it previously returned LogTruncateSize it would have returned a $null value. 🤔

Using the parameters you used to hit this bug, could you with those create a new unit test for each function, that catch this bug (and with you fix the tests passes)?

[stale]

Labeling this pull request (PR) as abandoned since it has gone 14 days or more since the last update. An abandoned PR can be continued by another contributor. The abandoned label will be removed if work on this PR is taken up again.