Re: Need for unit testing changing the code?
That's an option I should have added to the list, you're right. It does mean we are not exercising the code that we're shipping, but it's probably better than nothing. Milan On 2013-05-30, at 3:46 PM, Joe Drew j...@mozilla.com wrote: On 2013-05-30 3:14 PM, Milan Sreckovic wrote: I'm thinking C++, I imagine JS may have different answers or suggestions. Do we have a precedent or a preferred approach when unit testing requires changes or additions to the code? I've needed to do this in the past and resorted to an entirely different interface (imgIContainerDebug http://mxr.mozilla.org/mozilla-central/source/image/public/imgIContainerDebug.idl, only implemented in debug builds) to expose my unit test bits. I don't know what others have done, though! joe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Need for unit testing changing the code?
On 2013-05-30 3:14 PM, Milan Sreckovic wrote: I'm thinking C++, I imagine JS may have different answers or suggestions. Do we have a precedent or a preferred approach when unit testing requires changes or additions to the code? I've needed to do this in the past and resorted to an entirely different interface (imgIContainerDebug http://mxr.mozilla.org/mozilla-central/source/image/public/imgIContainerDebug.idl, only implemented in debug builds) to expose my unit test bits. I don't know what others have done, though! joe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Need for unit testing changing the code?
For example, a public method (which we want to test in the unit test) has a number of side effects, but we don't have the public accessors to examine all of those private side effects/state. I had this problem with the B2G process priority tests. From a mochitest, I wanted to create a variety of circumstances which would cause a side-effect in hal. But hal doesn't keep track of this state -- it sends it off to the OS and forgets it -- and it provides no way of reading the state. What I did was create a pref which, when set, causes my code to fire observer notifications when it calls into hal. Then I can listen to these notifications from my mochitest. Effectively, we're mocking the hal interface. I'm not sure this is a good solution everywhere, but it has worked well for my needs in this case. The tests are in dom/browser-element/mochitest/priority, and the code is in ProcessPriorityManager.cpp (search for testonly), if you want to have a look. -Justin Add public accessors, even if they're (currently) only used by the unit tests. Make the private members protected, derive a class inside the unit test code and put the public accessors there. Make the unit test class a friend of the original class so that it can access private members. Extend the signature of the method in question to allow the return of all the side effects. Take the fact that you can't see side effects as a sign of bad design, because that means the non-unit test code cannot check if the right thing happened. (I imagine that would lead to #1 or #4 or some combination of those.) Thoughts or precedents? Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Need for unit testing changing the code?
On 5/30/13 3:14 PM, Milan Sreckovic wrote: Add public accessors, even if they're (currently) only used by the unit tests. If it doesn't hurt, this seems like a pretty good solution. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Need for unit testing changing the code?
On 2013-05-30 3:14 PM, Milan Sreckovic wrote: I'm thinking C++, I imagine JS may have different answers or suggestions. Since you mentioned C++, here is an example of an entire class [1] which I had to invent so that I can test it [2] in C++. The Gecko consumer derives [3] from this class, and in the test I just use the base class itself, and I make sure that all of the interesting logic lives in the base class always. [1] http://mxr.mozilla.org/mozilla-central/source/content/media/AudioEventTimeline.h#151 [2] http://mxr.mozilla.org/mozilla-central/source/content/media/webaudio/compiledtest/TestAudioEventTimeline.cpp [3] http://mxr.mozilla.org/mozilla-central/source/content/media/webaudio/AudioParamTimeline.h#27 Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
