Test methods called by another method
I have a class with a method DataIn(int InputID, string CSVValue)
, this is the main entry point to it.
This method, based on InputID
, stores the CSV Value parameter in the appropriate List<string>'s
. When it InputID
matches a property NoOfRows
, it creates one List<string>
made up of all the others. Then he validates this final List<string>
, if everything is ok then he adds the results in HashSet<int>
as a quick way to check for duplicates.
I broke this logic into 3 methods, so DataIn calls StoreData when InputID in DataIn = NoOfRows calls MergeData which calls ValidateData.
My question is whether I should publish these methods to test them separately, or should I keep them private and pass the DataIn data, and do statements on the combined data List<string>
and HashSet<int>
. DataIn will be a method that is called from outside the class, making other methods public only for unit testing.
I am concerned that if I make the other methods public and check if they are ok then I am not testing the DataIn as expected, or if I do both I end up with duplicate tests.
What's your advice?
source to share
Always stick with it principle of least privilege
. Exposing private methods as public in order to make them a single testable is not good design. Instead, stick to testing only public interfaces
. If a method behaves differently with different inputs, make sure you write a test for the expected behavior and you must have a clean and clean design while still being testable.
source to share
There are two competing schools of thought about testing private methods - they say you shouldn't test them because they are implementation details; the other says that you should test them because you need to test everything.
Without getting to the middle of the argument between the two, I should mention that both sides have valid points for their approach. However, one thing you should avoid is to make your potential private methods public for the sole purpose of testing them. If you choose to go with the private method validator approach, you must make those methods internal, not public, and let the test assembly see the internal methods using InternalsVisibleTo
in your target assembly.
source to share