Is implementing ICloneable in unittests worthless?
ICloneable of course we use to clone reference type variables since they point to the same memory address which implies that any changes to the original reference (like string1) will also change all copies (like string2) that aren't cloned with ICloneable.
Now I haven't used ICloneable in unittests before, but it seems that it doesn't work. Perhaps it is because there's a conflict with other interfaces, or packages in the csproj, all that stuff that on my level (1st year student without foreknowledge) I wouldn't know about, so that's why I'm asking, what are your experiences? Is my hypothesis of internal conflicts possible, or is ICloneable really just worthless on unittests?
1 Reply
It is likely that no one will read this anymore, but that makes it all the more funnier.
So the reason Deepcloning didn't work was because I was working in a Mock environment. I was mocking File I/O but instead of loading the mocked file I was loading the original file, which means I was returning the same objects, so I was changing the same returned object as well ðŸ˜