Archive for January, 2009

Getting started

January 31, 2009


Build the minimum needed to make a working ZeeTest binding for python, ruby, and javascript.


A spike solution (with minimal tests) with server-side code in Python and browser code in Javascript works. The existing kernel code is bloated and contains naive and bogus code that I wrote years ago when I understood neither Python nor Zeetix. Buried inside that is the prize.


  1. clone the relevant parts from Python into a Python binding of ZeeForge, driven by the requirement to make ZeeTest (and ZeeTestTest, ZeeTestUI::TestApplication, and so on) work.
  2. Construct and rely on test case assemblies in KernelTest — CoreTest, AssemblySupportTest, and others — to assure the continued correct behavior of the relevant Kernel modules as I remove the crud.
  3. When done (or along the way?), I clone/copy the result to Ruby, ensure that the Ruby binding also works.

Meanwhile, I need the minimal SQL and database that supports it. I think that’s there, I wonder how this is tested. This sounds like a TestResource (for other tests), and also has its own tests.

New Tests

  • KernelTest.KernelCoreTest.KernelCoreLoadsTest: Validates that the Kernel.Core clazzes have been loaded.
  • KernelTest.AssemblySupportTest.AssemblyLoadUnloadTest: Validates that assemblies can be loaded and unloaded.


  • I created KernelTest to hold the tests needed to preserve the integrity of the Kernel.
  • Created KernelCoreLoadsTest in KernelTest, because the CommandLineLauncher needs to have the KernelCore in order to do anything uself.
  • This already requires me to add KernelTest and such to SystemConfiguration (in Kernel/AssemblySupport), currently as an explicit import. This is WRONG WRONG WRONG. I need to load and unload assemblies — so I need to add tests to KernelTest/AssemblySupportTest
  • Thus, I created “AssemblySupportTest/AssemblyLoadUnloadTest”.
  • AssemblyLoadUnloadTest will have profound implications for SystemConfiguration, because assemblies will need prerequisite/dependent machinery — machinery that doesn’t exist today.
  • As I discover needed tests in Ruby, I’m building them in Python and validating that they work. The plan is to then use those tests to keep things working while I slash unnecessary junk from the existing Python code.