Hi Erik,<br><br>It is really good to read such things but I have also some questions:<br><br>1a. Does Continues Integration system contain automated testing? It would be good to see what is going on with each build.<br>1b. Maybe we should also provide some examples, descriptions, information where we can find, how we can create and manage these tests.<br>
1c. There should be also provided some information what kind of tests, frameworks and test suits we currently use/have.<br>1d. Which parts of editor/code model have some tests and where. For example:<br><ul><li>code-completion - there are unit tests in cppcompletion_test.cpp<br>
</li><li>highlighting (both syntactically and semantically)</li><li>navigation (the locator, follow symbol, etc)</li><li>introspection (the class browser, the outline, etc)</li><li>diagnostics and tool-tips</li><li>find usages and renaming</li>
<li>refactoring actions - currently there are some unit tests but only for InsertionPointLocator(cppcodegen_test.cpp)<br></li></ul><br>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.<br>
<br>Best Regards,<br><br>Przemek<br><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 1:00 PM, Erik Verbruggen <span dir="ltr"><<a href="mailto:erik.verbruggen@digia.com" target="_blank">erik.verbruggen@digia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
First of all, to all whom it's applicable: a happy new year! (To all<br>
whom it's not: you can save it for the next one .)<br>
<br>
As customary, we made a couple of new-year's-resolutions that I would<br>
like to give you a heads-up on. It is specific to the<br>
editors/code-models area (so if you are not sending us patches, stop<br>
reading now). I could rant about deep personal inflection, but let's<br>
just skip those details. It comes down to just 3 little things, being:<br>
<br>
1) For every change/patch that changes behaviour, we will add a test-case.<br>
2) For every change/patch, we will add documentation to the<br>
method/function/variable we touch.<br>
3) For every change/patch that we review, we will -1 it when either (or<br>
both) of the previous items is not present, no matter who submits it.<br>
And you are welcomed to vote us down too, which we'll take seriously.<br>
<br>
The ONLY exception is for brown-paper-bag bugs, but for that the we<br>
already has the policy to force the Guilty Party to wear a brown paper<br>
bag for a day. (Brown-paper-bag bugs are those bugs that you find<br>
shortly before or after a release that are hugely embarrassing, and want<br>
you to put a brown paper bag over your head in order not to be recognised.)<br>
<br>
Clarification (or foot-notes or The Details or whatever you want to call<br>
it) for each item:<br>
<br>
1) We have had too many cases where we added a feature or fixed<br>
something, but where we unintentionally broke something else. We all<br>
know that fixing a problem is the easiest when you are into it, so I<br>
think this is a case of QED. Of course, we don't need tests for<br>
additions of simple getters/setters or for cosmetic/style corrections.<br>
Oh, and existing tests must all pass, of course.<br>
<br>
Now we know that certain changes are very visual. If you have such a<br>
change, that's fine and it doesn't need a test, as long as the<br>
infrastructure/logic/etc. has one. If you run into an area which doesn't<br>
only lack tests, but even the basic infrastructure is not there, then<br>
please let us know!<br>
<br>
2) Let's start with the things we're not looking for: it's the kind of<br>
documentation for a simple getter or setter method that, well, gets/sets<br>
a field of a class. Instead of that, write an understandable comment on<br>
why that field is there. Or, when you add/change an algorithm, add a<br>
comment on why it is there or what it does. We are also perfectly happy<br>
with references to standard documents (e.g. "[16.3.4] item 3" or similar<br>
when you are in the C++ parser).<br>
<br>
3) I think it's just fair to exchange: the maintainers are expected to<br>
take the responsibility for code in their "allocated" area(s), which<br>
(among things) means that people will knock on your door when things<br>
break down.<br>
<br>
Best regards,<br>
Erik.<br>
_______________________________________________<br>
Qt-creator mailing list<br>
<a href="mailto:Qt-creator@qt-project.org">Qt-creator@qt-project.org</a><br>
<a href="http://lists.qt-project.org/mailman/listinfo/qt-creator" target="_blank">http://lists.qt-project.org/mailman/listinfo/qt-creator</a><br>
</blockquote></div><br>