Roman Neuhauser wrote: > # jochem@xxxxxxxxxxxxx / 2007-01-14 20:47:02 +0100: >> Roman Neuhauser wrote: >>> I have a circular dependency, and am looking for thoughts on breaking >>> the cycle without (much) redundancy or hard to automate procedures. >>> >>> I'm developing two programs, Testilence, a unit testing library, and >>> Amock (library for mock object generation, but that's irrelevant in this >>> discussion); both programs have unit tests based on Testilence, but >>> Amock itself should not depend on Testilence, and neither should contain >>> (or depend on) nontested code. >>> >>> Testilence contains some utility classes I'd like to use in Amock (or >>> indeed, anywhere). I could "fork" them, but would like to avoid this >>> if at all possible. I think I can't pull them out into a separate >>> library for both Amock and Testilence to depend on because that would >>> create a dependency loop between the utility and Testilence since I'd >>> like to keep using Testilence for the utility's unit tests. >> isn't there a circular dependency anyway? given that you unit test >> Testilence with Testilence? > > I should've stressed that I'm coming from the packaging side (think RPMs > or such). You can run Testilence's test suite without having Testilence > installed (both are in the same tarball), so there's no cycle. > > The goal is to make a successful run of the test suite a prerequisite of > the utility installation... Think RPM or similar: if X.rpm depends on > Y.rpm in runtime, you cannot make Y's installation depend on execution > of commands from X. ok, I'm not grokking this fully - I'll just have to take you word on it :-) > >> if these utility classes are utility classes I wonder whether it's not better >> if they have no external dependencies? > > That depends on relative merits in individual situations, I cannot > answer this question as is either way. > >> whilst reading about Testilence I remember coming across a mention of runkit > > runkit is mention because I'm considering its use for better test > isolation, I haven't thought of using it for "normal" code. > >> ... whilst I wonder whether using runkit for anything other than experimental >> stuff, could runkit not offer a solution (e.g. renaming the class dependent on >> the context of it's usage)? probably not, right? > > How would this work? from looking at runkit it would seem using runkit_import() would work, it would mean you simply 'include' the utility class(es) in both Testilence and Amock using runkit_import() and that would simply cause the second 'include' to overwrite the class definition of the first include. this could also be tackled using a chain of __autoload() functions. either way having a runtime dependency in your code is probably not a good idea even for a develop-time tool like yours is (because it's marked experimental and it raises the bar as to the getting your tool working) > >>> Both Amock and Testilence are versioned using Subversion, so I could >>> leave the classes in Testilence and use svn:externals to put them in >>> Amock too. That would lead to name clashes if both programs were used >>> together, and that is a showstopper. >> given that they are the same code would conditional loading of the utlity >> classes not work? i.e. only load if they don't already exist > > That seems quite fragile, but I admit I haven't thought it through. unless the class is called something silly like 'Foo' or 'Utility' then I think that in practice the problem is negligable. > >> this could be augemented with the use of a [number of] Interfaces - if >> the class already exists and doesn't implement the required interfaces >> then your code bails out. > > I'm not concerned about the user who's *attempting* to shoot himself in > the foot, I'm worrying about my code shooting an unsuspecting user in > the butt. from what I read it should be possible to at least give the user clear feedback as to why he has a hole in his foot - proper feedback should be enough for the user to address the problem. and if the user is defining his own RNeuhauserTestUtility class (or what ever you decide to call it ;-) then he probably needs some feedback! I think that a suitably 'weird' name for the class in question should be enough in practice to avoid problems (even if theoretically it's not an optimum solution) > > So far I'm leaning towards pulling the utility out from Testilence, > sacrificing the ability to unit test the library without jumping through > hoops. that seems sane - hopefully the utility won't change half as often as the 'real' tools and given that you test the utility yourself before packaging you know that it works ... maybe including your test results in the utility package is something to consider? > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
