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

[P Zoltan]

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.

>
> The other day, we talked about loading plugins from the TestCore. It  
> seams to
> work for me, now. The KTLProject plugin is somewhat special, because it  
> isn't
> "loaded" (and so it doesn't show up in KDevelop::Core::self()-
>> pluginController()->loadedPlugins()). This is, because it is a "project"
> plugin and not a "global" one. KTechLab::Circuit, however, does show up  
> in
> this list. For me it works, when I have KDevPlatform installed from my
> distributions packages and have KTechLab installed into my personal  
> prefix. (I
> had to run kbuildsycoca4, of course.) I tested using KDevPlatform 0.9.99  
> and
> KDE SC 4.4.2. From #kdevelop I learned, that konsolepart has a bug in  
> KDE <
> 4.4.0 and it will crash the TestCore, during initialization with GUI  
> setup
> flags.

  It seems to me that after building, installing and setting up ktechlab
( maybe some auto-generated launch-script, or kbuildsyscoca4 scribpt would  
be nice)
the tests seem to work.

>
> So all in all, this seems still somewhat fragile and it seems to work  
> best,
> with later versions of KDevPlatform. But I think, this situation will  
> get more
> mature as soon as the first stable version of KDevPlatform is released.  
> Since
> we are talking about automatic tests here, IMHO we can be a bit more  
> strict
> about the used libraries. At least for now. I don't want to spend much  
> time
> working around bugs in older versions, just to make test-cases run
> everywhere...
>
> You can find the code in the kde4-ktlproject branch. I will complete  
> these
> test-cases, soon. Now, as it works, this should be an easy task ;) and  
> after
> that, implement all missing functionality for project management.

  Thanks, thested that, some test-cases work, but others dont. It seems to  
fail at renaming some part of the project.

  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".

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.

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?

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.


  Finally, as we are talking about test-cases: the tests for math classes  
were actually broken, that is why they passed so easily. They're  
supposedly fixed in my git repositroy. Now only about half passes, the  
rest are tests with sparse matrixes with mostly no solutions.


>
> bye then
> julian
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel