# 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. > 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? > > 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. > 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. So far I'm leaning towards pulling the utility out from Testilence, sacrificing the ability to unit test the library without jumping through hoops. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
