Unit testing (once again)

[Miha Čančula]

2012/2/8 Milian Wolff <mail at milianw.de>

> Aleix Pol, 08.02.2012:
> > On Wed, Feb 8, 2012 at 5:23 PM, Miha Čančula <miha at noughmad.eu> wrote:
> > > 2012/2/8 Aleix Pol <aleixpol at kde.org>
>
> <snip>
>
> > >> To extract the information, the view plugin will load all the plugins
> > >> that implement the UnitTestProvider interface and ask for the provided
> > >> information. Here's some rough idea of what I think this interface
> > >> might have looked like.
> > >>
> > >> class Test {
> > >>   QString executable(); //maybe a launcher?
> > >>   QMap<QString, QStringList> cases(); //test name with the arguments
> > >> to pass to the execution
> > >> };
> > >>
> > >> class IUnitTestProvider {
> > >>    virtual QMap<KUrl, Test> retrieveTests() = 0;
> > >> };
> > >
> > > This is basically what I had in mind, except for the tree structure
> (and
> > > asynchronous operation, and checking whether this particular provider
> is
> > > the right one for a project). My question is where to put the Test
> > > class. It's possible to avoid it altogether by replacing it with a
> > > QPair<QString, QStringList> or something even more convoluted, but that
> > > looks ugly. On the other hand, an ugly typedef is still better than a
> > > whole separate library.
> >
> > It has to be together with the interface, because the interface
> > depends on it. I think it's fine if it's inside interfaces.
>
> Just make it a pure abstract interface as well.
>
> namespace KDevelop {
> class ITestSuite
> {
>  ILaunchConfiguration* launcherForAllCases() const  = 0;
>  ILaunchConfiguration* launcherForCase(const QString& case) const  = 0;
>  ILaunchConfiguration* launcherForCases(const QStringList& cases) const  =
> 0;
>
>  QStringList cases() const = 0;
>
>  KUrl url() const = 0;
> };
> }
> Q_DECLARE_INTERFACE(KDevelop::ITest)
>
This looks clean, but I think at least the data members (list of cases,
url, name) don't have to be virtual.

>
> And personally, I would rather create a test controller where unit test
> suites
> can be added/removed. I.e.:
>
> class ITestController
> {
>  void addTestSuite(ITestSuite* suite);
>  void removeTestSuite(ITestSuite* suite);
> };
>
> This way plugins can easily add test suites by just implementing a
> ITestSuite
> class and registering it at the controller.
>
So you want global testproviders to be global plugins with no interface
that float around, look for tests and report them? Sounds simple enough on
the plugin side, but isn't that a slight waste of resources? And the
controller would have to be globally accessible, in shell perhaps?

>
> something like that.
>
Well, I started writing code with something like that.

>
> cheers
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120208/8c571047/attachment.html>