Archive for January, 2009

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

Context

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.

Strategy

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.

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.

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.

Notes

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.