Skip to main content
26 events
when toggle format what by license comment
Jan 12 at 21:56 comment added David Mason I decided to make my question more clear, so I asked the question again here: softwareengineering.stackexchange.com/questions/456341/… This can be closed. Sorry for the confusion :-/
Jan 11 at 14:31 history reopened candied_orange
Greg Burghardt
Thomas Owens
Jan 10 at 21:08 history edited David Mason CC BY-SA 4.0
added 97 characters in body
Jan 10 at 21:07 comment added David Mason Yes, I'm fine with the title change
Jan 10 at 18:25 comment added Greg Burghardt If the OP is good with it, I think it clarifies the question. +1 and I voted to reopen.
Jan 10 at 18:06 comment added candied_orange @GregBurghardt better now?
Jan 10 at 18:06 history edited candied_orange CC BY-SA 4.0
edited title
Jan 10 at 18:00 comment added Greg Burghardt David, can you edit your post to clarify your question? The title and body appear to be asking different things, and "how to do X" is difficult to answer because we don't have a clear problem statement. Be sure your edit does not invalidate existing answers. If it does, consider posting a new question with the updated info instead.
Jan 10 at 17:57 comment added Greg Burghardt The post titles sounded similar. Maybe the title of this post is misleading then?
Jan 10 at 17:49 comment added candied_orange @GregBurghardt maybe I missed it. Where does that post deal with not duplicating tests?
Jan 10 at 17:47 review Reopen votes
Jan 11 at 14:31
S Jan 10 at 16:31 history closed gnat
Doc Brown
Greg Burghardt
Needs details or clarity
S Jan 10 at 16:31 comment added Greg Burghardt This question is similar to: How do you unit test private methods?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.
Jan 10 at 16:06 comment added candied_orange @DocBrown right! Ignoring the structures and focusing on the behavior will guide you through this. I tried to underline that point by throwing an adapter around method2 on the off chance that their API's are different enough to break the tests. So long as the expected behavior is the same we can fit this round peg in the square hole. Structure is just a distraction. Prove the behavior!
Jan 10 at 15:34 comment added Doc Brown ... but here @candied_orange's suggestion applies: one can write all tests only once but use them to trigger both method variants. Another case would be when you have two methods with different functionality, but sharing some private "tools". Here, the answers apply which say "focus on the contract, ignore that you know there is some shared functionaility", And there are also middle-ground cases, or (rare) cases where it can pay off to test the private methods directly.
Jan 10 at 15:28 comment added Doc Brown ... as we can see from the answers, I think it makes a pretty huge difference whether we speak of two public methods sharing most of the common logic under the hood, or whether there is only a little bit of functionality shared. For example, when you offer the user of the class different ways to access almost the same functionality by different variants of the input parameters - like a DrawLine function which can work with a Point type, or pairs of (int x,int y), or pairs of (double x,double y). It would make no sense to write all tests twice for such a case ...
Jan 10 at 14:43 answer added VoiceOfUnreason timeline score: 1
Jan 10 at 14:16 comment added Jon Raynor One set of tests should completely test the private functionality. If you have another public method calling the same private method, then you only need tests to cover the different public functionality for that second public method. Retesting the private method's functionality is not needed because that other set of tests are already covering it. Or, you could make the private method public and have separate tests for it and for each of the methods calling it.
Jan 10 at 13:42 comment added Doc Brown I think this question would benefit from making it less abstract and extending it by some realistic example. What you described fits to so many different situations that there are also many different solutions, and whether it makes sense to duplicate all the testing logic, or none of it, or parts of it depends heavily on the specific case.
Jan 10 at 13:06 answer added candied_orange timeline score: 1
Jan 10 at 12:00 answer added Joop Eggen timeline score: -1
Jan 10 at 11:21 answer added Thomas Owens timeline score: 4
Jan 10 at 8:46 answer added Bart van Ingen Schenau timeline score: 0
Jan 10 at 8:25 review Close votes
Jan 10 at 13:35
Jan 10 at 8:24 answer added nvoigt timeline score: 7
Jan 10 at 8:02 history asked David Mason CC BY-SA 4.0