[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: More on C++ tests
From:       Nicolás_Alvarez <nicolas.alvarez () gmail ! com>
Date:       2010-06-29 4:02:30
Message-ID: AANLkTinLKuEdkUiVMo21aRsAEJB3gLF6QjGNH7r2OaW9 () mail ! gmail ! com
[Download RAW message or body]

On 6/19/10, David Nolden <zwabel@googlemail.com> wrote:
> The problem with both test_duchain and test_cppcodecompletion is that
> they have an own replacement for the background parser and the whole
> parsing architecture in kdevplatform/kdevelop, because that one didn't
> support testing at that point.

It's not a replacement for the whole parsing architecture. It's
something *much* simpler, staying in a single thread, not using
ParseJobs, not using the preprocessor when it's not needed, etc.

> However that problem has been fixed, and now we can use the _whole_
> kdevplatform/kdevelop architecture for the tests, which is done in
> test_cppcodegen, using the InsertIntoDUChain helper class, and in
> long-term it might make sense to port the other tests to the same
> architecture.

Then I guess I'll have to stop calling them "unit tests" :)

The "unit" being tested would be the C++ parser. If the test also uses
the background parser, language-to-plugin lookup, include path lookup
(PreprocessJob::sourceNeeded is amazingly complex), etc. that's not a
unit test anymore, that's an integration test. It's adding in a lot
more code that could interfere with the result.

-- 
Nicolas

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]