> 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
