Page MenuHomePhabricator

[WIP] [clangd] Tests for special methods code-completion
Needs ReviewPublic

Authored by jkorous on Sep 26 2018, 8:03 AM.



Created in order to check we agree on what are the requirements and would later write patches against these.

Currently these are failing:
[ FAILED ] CompletionTestNoExplicitMembers.Struct
[ FAILED ] CompletionTestNoExplicitMembers.StructTemplate
[ FAILED ] CompletionTestNoExplicitMembers.ExplicitStructTemplateSpecialization
[ FAILED ] CompletionTestMethodDeclared.ExplicitStructTemplateSpecialization
[ FAILED ] CompletionTestSpecialMethodsDeclared.Struct
[ FAILED ] CompletionTestSpecialMethodsDeclared.StructTemplate
[ FAILED ] CompletionTestSpecialMethodsDeclared.ExplicitStructTemplateSpecialization

Diff Detail

Event Timeline

jkorous created this revision.Sep 26 2018, 8:03 AM

The assertions themselves all look good to me.

I don't think these should be new tests, they have substantial overlap with TestAfterDotCompletion and should be incorporated there or those tests split up to reduce the duplication.
(It's hard to avoid overlap/redundancy between tests, and to do so while covering all cases in a systematic way, but it's important for maintenance: one of the reasons it's hard to find the overlapping test here is there are so many!)

2043 ↗(On Diff #167140)

(Should this be ImplicitMembers?)

2043 ↗(On Diff #167140)

nit: these cases should probably be moved up with the other code completion ones, and called something like TEST(CompletionTest, NoExplicitMembers) or so for consistency.

It's OK to have related tests in one test case.

In fact, this large set of closely-related cases seems like a good place for Go-style table-driven tests.

2045 ↗(On Diff #167140)

(not clear why the limit is needed?)

2054 ↗(On Diff #167140)

EXPECT_THAT(ResultsDot.Completions, IsEmpty())

(when the assertion fails, the failure message will print the contents of the container)

2139 ↗(On Diff #167140)

doesn't this test a strict superset of what CompletionTestNoTestMembers tests?
i.e. this also asserts that the implicit members are not included.

ISTM we could combine many of these tests (and that in fact many of them are covered by TestAfterDotCompletion.

2150 ↗(On Diff #167140)

EXPECT_THAT(ResultsDot.Completions, ElementsAre(Named("foomethod")));

(As above, this is equivalent to the two assertions here but gives useful failure messages)

2338 ↗(On Diff #167140)

(I think we could get away with a representative set of cases, rather than testing the intersection of every feature. e.g. test an explicitly declared operator= on a struct, but combining that with an explicitly specialized struct template seems unneccesary)

jkorous marked 6 inline comments as done.Nov 7 2018, 7:03 AM
jkorous added inline comments.
2043 ↗(On Diff #167140)

Ultimately got rid of the name completely.

2043 ↗(On Diff #167140)

I reconsidered the simple yet verbatim approach.

2054 ↗(On Diff #167140)

I didn't know this. It's pretty neat. Thanks!

2139 ↗(On Diff #167140)

You are right, I pruned the list of testcases a bit.

2338 ↗(On Diff #167140)

I simplified the whole test and removed some cases that were not really unique. Do you think the rest is still too exhaustive? (Asking before deleting.)

jkorous updated this revision to Diff 172951.Nov 7 2018, 7:04 AM
jkorous marked 4 inline comments as done.

Rewritten tests to shared implementation different cases.