Unit-Tests that uses projects

Manuel Breugelmans mbr.nxi at gmail.com
Sat Aug 16 10:10:15 UTC 2008


On Saturday 16 August 2008 10:37:45 Niko Sams wrote:
> Hi,
>
> For the Php support one feature is to auto-complete classes from all
> open projects. To write
> an unit-test for this I need an open project. So I implemented a
> KDevTestProjectManager, that does
> basically nothing other than implemeting addFile and addFolder (it
> doesn't stores the files, after a
> restart everything is gone).
> So my question is how to use it, should it be installed?

Best is to increase the testability of your unit under test with an extra 
layer of indirection. There's two decent options:

1/ non-intrusive

class PhpCodeCompleter
{
protected: virtual IProjectFileManager* projectFileManager(IProject* proj) { 
return proj->projectFileManager(); }
};

Your code will then always access the manager through this method. In the test 
you subclass:

class PhpCodeCompleterTestFake : public PhpCodeCompleter
{
protected: IProjectFileManager* projectFileManager(IProject*) { return new 
TestProjectFileManager; }
};

2/ normal dependency injection [don't think this will work well in your case]

class MyCodeCompleter
{
public: void setProjectFileManager(IProjectFileManager*);
private: IProjectFileManager* m_pfm;
};

Client classes will inject a real manager, tests will inject the stub. You 
could also do this with a constructor argument instead of setter.

A third solution is to get rid of the IProjectFileManager dependency 
altogether and hide it behind your own lightweight abstraction. I'm not sure 
this is viable in your case though. Eg the code completer should only care 
about parsed data, not actual files. The code that accesses the project file 
manager could be locked away in it's own trivial class that doesn't require 
testing.

> and my second question: I need the files in kdevplatform/tests/common/
> for my test, how could I do that?
>

I suppose they should either be copied or installed. Note that with the 
injection way of doing things you don't need to setup a full core (which is 
slow).


Manuel




More information about the KDevelop-devel mailing list