[wix-devs] Writing unit tests

[Ron Martin]

Jacob,

I haven't read the document  you referenced, but "back in the old days", 
before RAM sizes went through the roof, the
fact that all active registry hives were kept in physical memory was 
certainly enough motivation to follow that advice.
It's the old space/time trade off.

Ron

On 6/15/2021 12:36 PM, Hoover, Jacob via wix-devs wrote:
> Also note I chose to keep the binary RSM as a file instead of a binary value in the registry due to the recommendation on https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw , remarks, Long values (more than 2,048 bytes) should be stored as files, with the locations of the files stored in the registry.
>
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
> Sent: Monday, June 14, 2021 2:07 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Writing unit tests
>
> I don't think it makes sense to write or maintain a mock implementation for
> unit testing butil.
>
> On Mon, Jun 14, 2021, 09:55 Hoover, Jacob via wix-devs <
> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>> wrote:
>
>> I should say BundleGetBundleInfo more so than BundleEnumRelatedBundle, but
>> I think both can be cleaned up to take a pointer that the API can
>> reallocate to return the value without needed to call it once to get the
>> size, and then call it again to get the actual value.
>>
>> I think the cleanup of those two methods should be under a different
>> commit. I really want to get the BundleGetBundleVariable change in, along
>> with the RegistrationSaveState change.
>>
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
>> Hoover, Jacob via wix-devs
>> Sent: Monday, June 14, 2021 10:13 AM
>> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
>> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>
>> Subject: Re: [wix-devs] Writing unit tests
>>
>> The other option I can see is to have a hard coded expectation implemented
>> to prime the redirected registry, just for the purpose of reading the
>> values back from BundleGetBundleVariable. At this point, I don't know if
>> that would be worth the time to write and maintain it.
>>
>> Turns out, the test cases bundle authoring was just wrong. Best I can tell
>> is the bundle wxs for UpgradeCode ends up with a <RelatedBundle Id="..."
>> Action="Upgrade" /> So the test case is just flawed.
>>
>> I'll clean up the commented authoring for the new method, should we also
>> do the same for the BundleEnumRelatedBundle?
>>
>>
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.wixtoolset.org>>> On Behalf Of Sean Hall via
>> wix-devs
>> Sent: Saturday, June 12, 2021 6:49 PM
>> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org
> <mailto:wix-devs at lists.wixtoolset.org%0b>> <mailto:wix-devs at lists.wixtoolset.org>>
>> Cc: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com%3cmailto:r.sean.hall at gmail.com>>>
>> Subject: Re: [wix-devs] Writing unit tests
>>
>> Maybe it would have been different with micro repos, but in the monorepo I
>> think it makes sense for them to be in BurnUnitTest so that it's clear when
>> the real implementation gets out of sync with butil.
>>
>> I don't know why they're identical. That should never happen in a real
>> bundle so the test probably shouldn't do it either.
>>
>> I think the new butil API should allocate the string for the caller.
>> They're already using dutil anyway so it's natural to require the caller to
>> use strutil for strings.
>>
>> On Thu, Jun 10, 2021 at 5:11 PM Hoover, Jacob via wix-devs <
>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org<mailto<mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.org%3cmailto>:
>> wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.org>>>>
>> wrote:
>>
>>> Running into a bit of a chicken and egg scenario. I have the logic
>> written
>>> to store a copy of the persisted variables in the registry, and have the
>>> method for butil to expose BundleGetBundleVariable.
>>>
>>> Logically you'd think I would put the tests for the new API in the
>>> DUtilUnitTest project, but it depends on behaviors only happening out of
>>> burn. Is it sufficient to include the tests in BurnUnitTest?
>>> Currently I hijacked RegistrationTest::ResumeTest and added asserts for
>>> reading the variables with both the managed registry class as well as
>>> BundleGetBundleVariable.
>>>
>>> Finally, is there a reason why the unit test bundle ID's are identical to
>>> their upgrade codes?
>>>
>>> Thanks,
>>> Jacob
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Developer Mailing List provided by FireGiant
>>> http://www.firegiant.com/<http://www.firegiant.com><http://www.firegiant.com<http://www.firegiant.com>><
>> http://www.firegiant.com<http://www.firegiant.com><http://www.firegiant.com<http://www.firegiant.com>>>
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/<http://www.firegiant.com/><http://www.firegiant.com/<http://www.firegiant.com/>><
>> http://www.firegiant.com/<http://www.firegiant.com/><http://www.firegiant.com/<http://www.firegiant.com/>>>
>> NOTE: This email was received from an external source. Please use caution
>> when opening links or attachments in the message.
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/<http://www.firegiant.com/><http://www.firegiant.com/<http://www.firegiant.com/>>
>> NOTE: This email was received from an external source. Please use caution
>> when opening links or attachments in the message.
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/<http://www.firegiant.com/>
>>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/<http://www.firegiant.com/>
> NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/