I had originally intended to get ZUZU.TEST to its first release before spending much time on ZUZU.LIB, but for various reasons I have found myself adding code to it lately. In particular, I decided that my ExtendedDequeue-of class (a subclass of Dequeue-of with some extra useful methods) really should live in the ZUZU.LIB library instead of ZUZU.TEST. Of course, this means that ZUZU.TEST will need to depend on ZUZU.LIB while ZUZU.LIB will need to use ZUZU.TEST for its tests.
This presents a minor code organization issue. In order for packages in ZUZU.TEST to be able to import packages from ZUZU.LIB, the manifest for the former will have to delegate to the latter. Likewise, in order for the test packages in ZUZU.LIB to import the ZUZU.TEST.STANDARD package, the test manifest must delegate to the ZUZU.TEST library manifest. The problem is that Cyclical manifest delegation is not allowed in Curl so the ZUZU.LIB manifest may not delegate to ZUZU.TEST.
The solution is fairly simple, since the ZUZU.LIB library itself cannot depend on the ZUZU.TEST library, the tests for ZUZU.LIB can simply use a third manifest that contains entries for the test packages delegates to both libraries. In fact, what I did was slightly different than that. Instead of having my test manifest delegate to the ZUZU.LIB manifest, I had it include it so that the test packages and ZUZU.LIB packages would be loaded using the same manifest. This will allow me to use certain "white-box" testing techniques should they be necessary. For instance, I can create macros that add extra testing instrumentation when compiled using the test manifest (the macro can access the contents of the manifest in which it is expanded through its 'macro-env' variable). One aspect of this arrangement that may not be immediately obvious is that despite the fact that the test manifest includes ZUZU.LIB and its package entries, it is still considered a distinct manifest and its instances of the ZUZU.LIB packages are distinct from those loaded by the standard ZUZU.LIB manifest. In particular, this means that even though both are loaded from the same URL, the copy of the ZUZU.LIB.CONTAINERS package that is tested by the unit tests is different from the copy that is used in the implementation of the ZUZU.TEST infrastructure. For more information on manifest inclusion and delegation in Curl see the Manifests chapter of the Curl Developers Guide.
In any case, now that ZUZU.LIB is needed for ZUZU.TEST, I expect that I will do at least a skeleton release at the time I release ZUZU.TEST, but don't expect to do much in the way of testing or documentation, especially for the components not needed for ZUZU.TEST. However, that is not to say there is not useful code there, so don't be afraid to make use of it if it will help your project. I expect to write some blog entries on some of the things I have dropped in there recently, so stay tuned....
2008-08-24
2008-08-18
What I did on vacation
Despite the fact that it rained almost every day on our vacation, causing me to spend much time indoors, I did not end up getting all that much done on the Zuzu project. I mostly did some refactoring on classes in the REMOTE package in order to support accommodating remote test servers with different process configurations, i.e. different Curl API, debuggability, or even platform. My goal is for the test driver application to be able to dispatch to test servers with a variety of configurations so that developers can test multiple configurations from a common front-end.
I definitely missed being able to connect to the source repository, since it forced me to devise a manual system for doing check ins. Subversion does maintain local state, so you can at least track what files you have changed from the last time you committed your sandbox, but there is no facility to track individual changes while offline. I believe that I could have installed SVK and used it to mirror my repository, but it seemed like it would have been too much effort to set up, so I didn't try. Instead, I just created numbered folders for each discrete change, and copied any changed files when otherwise I would have submitted to the repository. When I got home, I reverted by sandbox, and then copied the contents of the numbered folders back into the sandbox and submitted the changes one at a time. All that file copying did slow me down a bit, and I will revisit the issue of doing offline checkins before I go on another long vacation.
I definitely missed being able to connect to the source repository, since it forced me to devise a manual system for doing check ins. Subversion does maintain local state, so you can at least track what files you have changed from the last time you committed your sandbox, but there is no facility to track individual changes while offline. I believe that I could have installed SVK and used it to mirror my repository, but it seemed like it would have been too much effort to set up, so I didn't try. Instead, I just created numbered folders for each discrete change, and copied any changed files when otherwise I would have submitted to the repository. When I got home, I reverted by sandbox, and then copied the contents of the numbered folders back into the sandbox and submitted the changes one at a time. All that file copying did slow me down a bit, and I will revisit the issue of doing offline checkins before I go on another long vacation.
Subscribe to:
Posts (Atom)
