Re: GNOME goal candidates

On Wed, 2017-03-01 at 07:26 -0600, Michael Catanzaro wrote:
It sounds like most everyone else supports installed tests. OK, then.

On Wed, 2017-03-01 at 10:22 +0000, Philip Withnall wrote:
I agree that developers need to be engaged with adding more unit
and code coverage if such a goal is to be useful. I wonder if
a goal would kick-start some people to do that? I don’t think we
ever expect the majority of maintainers to care about (or have
time to care about) code coverage and unit testing — but GNOME
have been useful catalysts in the past. I guess a suitably well
publicised and tutorialised blog post would work just as well

This is the other thing. The goals should be achievable, something we
can look at in a year or two and say "all apps meet the goal" and
it, not a longstanding epic that stays open forever. The installed
tests and coverage goals do not really qualify. Even though more
are definitely desirable, I don't think it's reasonable to use the
GNOME Goals project for this, even if it would be nice to see as many
projects as possible adopting it.

Maybe I am being too negative here. It does seem odd to say that
something desirable should not be a goal. But a longstanding pie-in-
the-sky project is very different from existing goals. Switching to
g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
all apps should be able to accomplish easily. Adding a comprehensive
testsuite, not so much. And adding just one or two installed tests,
while a good starting point, is not very useful on its own.

Porting a module to installed-tests is a fairly quick job. I’m not
suggesting the goal includes “write more tests” in its description. If
a module doesn’t have any tests already, then it doesn’t need porting
to the installed-tests infrastructure (instead, the infrastructure
should be added when tests *are* added to that module in future). The
advantage of porting everything to the infrastructure now is that all
new tests are then installed-tests by default, and hence appear in
Continuous, etc.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]