[Qt-creator] Editors/Code-models: new year's resolutions

[Przemyslaw Gorszkowski]

Hi Erik,

It is really good to read such things but I have also some questions:

1a. Does Continues Integration system contain automated testing? It would
be good to see what is going on with each build.
1b. Maybe we should also provide some examples, descriptions, information
where we can find, how we can create and manage these tests.
1c. There should be also provided some information what kind of tests,
frameworks and test suits we currently use/have.
1d. Which parts of editor/code model have some tests and where. For example:

   - code-completion - there are unit tests in cppcompletion_test.cpp
   - highlighting (both syntactically and semantically)
   - navigation (the locator, follow symbol, etc)
   - introspection (the class browser, the outline, etc)
   - diagnostics and tool-tips
   - find usages and renaming
   - refactoring actions - currently there are some unit tests but only for
   InsertionPointLocator(cppcodegen_test.cpp)


2a. Here I have only one doubt that after some time there will much more
comments then code but maybe it is not such a bad thing.

Best Regards,

Przemek


On Fri, Jan 11, 2013 at 1:00 PM, Erik Verbruggen
<erik.verbruggen at digia.com>wrote:

> Hello all,
>
> First of all, to all whom it's applicable: a happy new year! (To all
> whom it's not: you can save it for the next one .)
>
> As customary, we made a couple of new-year's-resolutions that I would
> like to give you a heads-up on. It is specific to the
> editors/code-models area (so if you are not sending us patches, stop
> reading now). I could rant about deep personal inflection, but let's
> just skip those details. It comes down to just 3 little things, being:
>
> 1) For every change/patch that changes behaviour, we will add a test-case.
> 2) For every change/patch, we will add documentation to the
> method/function/variable we touch.
> 3) For every change/patch that we review, we will -1 it when either (or
> both) of the previous items is not present, no matter who submits it.
> And you are welcomed to vote us down too, which we'll take seriously.
>
> The ONLY exception is for brown-paper-bag bugs, but for that the we
> already has the policy to force the Guilty Party to wear a brown paper
> bag for a day. (Brown-paper-bag bugs are those bugs that you find
> shortly before or after a release that are hugely embarrassing, and want
> you to put a brown paper bag over your head in order not to be recognised.)
>
> Clarification (or foot-notes or The Details or whatever you want to call
> it) for each item:
>
> 1) We have had too many cases where we added a feature or fixed
> something, but where we unintentionally broke something else. We all
> know that fixing a problem is the easiest when you are into it, so I
> think this is a case of QED. Of course, we don't need tests for
> additions of simple getters/setters or for cosmetic/style corrections.
> Oh, and existing tests must all pass, of course.
>
> Now we know that certain changes are very visual. If you have such a
> change, that's fine and it doesn't need a test, as long as the
> infrastructure/logic/etc. has one. If you run into an area which doesn't
> only lack tests, but even the basic infrastructure is not there, then
> please let us know!
>
> 2) Let's start with the things we're not looking for: it's the kind of
> documentation for a simple getter or setter method that, well, gets/sets
> a field of a class. Instead of that, write an understandable comment on
> why that field is there. Or, when you add/change an algorithm, add a
> comment on why it is there or what it does. We are also perfectly happy
> with references to standard documents (e.g. "[16.3.4] item 3" or similar
> when you are in the C++ parser).
>
> 3) I think it's just fair to exchange: the maintainers are expected to
> take the responsibility for code in their "allocated" area(s), which
> (among things) means that people will knock on your door when things
> break down.
>
> Best regards,
> Erik.
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20130112/e4892b61/attachment.html>