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 tests and code coverage if such a goal is to be useful. I wonder if making it a goal would kick-start some people to do that? I don’t think we can ever expect the majority of maintainers to care about (or have enough time to care about) code coverage and unit testing — but GNOME goals have been useful catalysts in the past. I guess a suitably well publicised and tutorialised blog post would work just as well though.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 close it, not a longstanding epic that stays open forever. The installed tests and coverage goals do not really qualify. Even though more tests 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 doing 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. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part