You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there are a number of unit tests that are more like examples instead of testing underlying class functionality.
This issue is to track the separation and expansion of unit tests to cover more of the functionality of DUnitX.
An example of a unit tests which is more an example than a unit test is like the following:
[TestFixture]
// if the "IgnoreMemoryLeaks" attribute is not specified, then all memory leaks will be reported.
[IgnoreMemoryLeaks(False)] // Report all leaks. This is the same as not specifying this attribute.
TTestsMemoryLeaksReported = class
published
[Test]
[IgnoreMemoryLeaks(True)]
procedure Override_No_Reporting_Of_Memory_Leaks;
[Test]
// if the "IgnoreMemoryLeaks" attribute is not specified, it will use the fixtures setting.
procedure Reporting_Of_Memory_Leaks;
end;
In a round about way it does test the memory leak functionality, yet it is as a whole rather than each of the units of functionality which make up that feature. The goal here is to break this down and "fake" the issues so that we control the outcome more closely in the unit test.
For example CheckMemoryAllocations could be passed a mock IMemoryLeakMonitor that simply reports that there has been a memory leak. This would test the unit of work CheckMemoryAllocations is doing more closely.
The text was updated successfully, but these errors were encountered:
Currently there are a number of unit tests that are more like examples instead of testing underlying class functionality.
This issue is to track the separation and expansion of unit tests to cover more of the functionality of DUnitX.
An example of a unit tests which is more an example than a unit test is like the following:
In a round about way it does test the memory leak functionality, yet it is as a whole rather than each of the units of functionality which make up that feature. The goal here is to break this down and "fake" the issues so that we control the outcome more closely in the unit test.
For example CheckMemoryAllocations could be passed a mock IMemoryLeakMonitor that simply reports that there has been a memory leak. This would test the unit of work CheckMemoryAllocations is doing more closely.
The text was updated successfully, but these errors were encountered: