[Ktechlab-devel] test-cases using KDevelop::Core

Julian Bäume julian at svg4all.de
Fri Apr 9 15:54:51 UTC 2010


On Wednesday 07 April 2010 12:44:51 P Zoltan wrote:
> On Fri, 02 Apr 2010 02:13:51 +0200, Julian Bäume <julian at svg4all.de> wrote:
> > hi,
> > as promised in irc, I tried to implement some test-cases using
> > KDevPlatform.
> > After fiddling around, hacking around and reverting most of my hacks, I
> > got
> > something working, now. This looks like how I expect a test-case to look
> > like.
> > This morning, I'm sure, I had something like that, but it somehow didn't
> > work.
> > After implementing a fake ProjectController and a fake Project it still
> > didn't
> > work, because some place in the KDevPlatform code still used some
> > variables, I
> > couldn't overwrite in my fake implementations. This was, where I gave up
> > and
> > removed all my fake implementations. Just for fun, I ran the test
> > again... and
> > this time it didn't crash -___-
> 
>   Same story here.
> 
>   As I've found, it's a bad idea to statically link to a plugin. That was
> the cause of the crashes.
:D I thought about that, too. Sometimes the plugin needs a running core to 
receive some managing classes or something else. So it's necessary to have an 
initialised core.


>   Also, based on that tests, I managed to create a test where a
> CircuitDocument is created. The bad part is that
> 
> core->documentController()->openDocument( url, preferredpart)
> 
>   doesn't seem to open a new document correctly. Instead of this method,
> I'm using:
> 
> core->documentControler()->factory("application/x-circuit")->create( url,
> core)
> 
> The problem with this approach is that the document donesn't gets opened
> in documentController, but only it's created.
> 
> Any idea how to create an empty document? It seems the url should be
> "Untitled".
Currently, there is no way to create new documents. At least I haven't 
implemented it, yet :D

> core->documentControler()->factory("application/x-circuit")->create( url,
> core)
That line seems to be the right choice. If you pass KUrl(), Core::self(), it 
should do the following things:
 * create a temporary file
 * put a valid XML skeleton into this file
 * create a new CircuitDocument and load the file

That should be done by an IDocumentFactory instance. This is created by 
KTLCircuitPlugin. There is already an implementation, which needs to be 
extended to handle empty KUrls.

> After looking to the source code ( kdevplatform 0.9.96,
> DocumentControllerInternal::openDocumentInternal ), it seem to me that
> currently is not possible. Also in that version, the PartsDocument is only
> read-only.
That's right. The default implementation is read-only. But our CircuitDocument 
should be able to do read/write.

> Another problem is that even if the circuitdocument gets created, i still
> can't access the documentModel. Maybe that's not really a problem, but
> some methods would be really needed for interaction with the document.
> Shouldn't be some interface for circuitdocument and flowcodedocument
> defined? Or from wher should the events from the user come?

The Document also needs a new method to return a DocumentModel. The model 
already has methods to add components (which need to be extended, I guess). 
The Document itself should only be responsible for saving and loading the 
document to/from a file. Everything else should be done via the Model.
 
> After this, a simulator interface should be defined, and/or maybe a
> simulationController ? If the simulator resides in a separate plugin, it
> means that the circuitdocument interface has do define a way to access its
> components.

Yes, somehow the model has to get into the simulator. My suggestion to handle 
this is to add a method to the SimulatorPlugin to receive DocumentModel 
instances and create new Circuit instances from that (and do all the other 
setup stuff) So the Circuit should decide which simulator to use. All possible 
simulators can be fetched from the Core. 

I think, I will find some time this weekend to do all this. (at least, I could 
come up with a suggestion for the new methods, that need to be added.) After 
that the test-cases can be written and the implementation of these methods can 
be started.

bye then
julian




More information about the Ktechlab-devel mailing list