Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
GPII-2927: Fixed code coverage for process reporter components. #604
@klown, I wanted to raise some points about the code coverage results, but can't link to line numbers because nyc isn't new enough. I'd suggest running npm outdated while you're there and at a minimum updating nyc, testem, and gpii-testem to the latest released versions. I did this locally, and saved a copy of the report here:
I wanted to ask you about a couple of branches that aren't reported as tested. In particular, I wanted to ask you about this one:
For whatever reason a process isn't returned, IMO you should be able to confirm that the system handles that appropriately. It may be that another fixture needs to be set up to report coverage, or that there simply aren't tests. If there aren't tests, let's talk through how hard it would be to add them, hopefully it's the kind of thing you can take care of in passing?
Also, things like these shouldn't be included in the report:
I'll try generating "node only" and "web only" reports to see who's creating those, depending on the results, we'll either need to update the NYC config or the gpii-testem component options. More on that in a bit.
@the-t-in-rtf Thanks for the comments! I think I have addressed them with the changes I've made -- have a look.
No, it's simple to add a test for that, and the other lines that were marked in red. I'm not sure about the lines marked with "Else path not taken", since there is no "else" path to take.
Sure, but isn't that a broader, global issue than improving coverage for the process reporter components? Perhaps another JIRA?
Hi, @klown. I understand what you mean, but I often am asked to (and take care of) small stuff that is unrelated to my immediate work as part of an active PR, and I tend to think it's fair game to fix small broken windows when we notice them. IMO it's more likely to result in immediate action than adding to our backlog of longstanding unreviewed pulls. For things that are outside the scope of the immediate work, I frequently create a ticket, and commit to the branch with that ticket's issue key, linking that ticket to the existing pull.
Whether or not you have a literal
To keep this specific, let's look at this example from the process bridge coverage report:
That to me indicates that although you allow passing
In some cases, we address this kind of gap by agreeing that the implicit
In the case I shared above, I think it's important to talk about why we allow that optional argument, and if we agree it's useful, to add tests to cover the implicit
Fair enough: I've created GPII-2936, and added the to-be-excluded-files to
D'oh! My question was literally and simply (and naively), "there is no else-block to check so how can I write a test for it?". But, as you noted, there is an implicit else in these cases. Of course there is. Chalk it up to it being late on a Friday afternoon... And, that's why you have reviewers, folks. Anyhow, I have added coverage for all the implicit else-blocks listed in the report.
Here's the rationale: for an actual OS*, it's relatively expensive to get the list of processes -- the
*- in these (universal) tests, the list is a mock and in memory, and getProcessList() is blazing fast.
New version coming up...
Thanks, @klown. With your additional tests and screening out the test content, the report is much clearer:
IMO the remaining gaps are fine to talk about in future pulls working in those areas, and nothing that should block this pull from being reviewed further.
I also confirmed the tests passing locally. Ok to test again in CI.
Weird. As you said, there are NullPointerExceptions in the general console log, but the logs for the browser and node tests show that all tests were run and passed (32 and 1256, respectively). Indeed the other console logs show that everything is tickety-boo. CI is schizoid.
I'm going to look more closely at the process reporter tests in the windows and linux branches for similar coverage issues that the work here revealed. I'll be using the tools in your GPII-2493 pull.
Hi @the-t-in-rtf . You mean that your GPII-2483 branch/pull for code coverage in Windows was merged. The pull request here (GPII-2927) is for Universal and is based its master branch. Still, it's a bit out of date, so I've merged in the latest from universal master, and pushed.
(And, I'll go rebase my Windows pull request as you suggest).