At my job we mainly use Python, an untyped language. However, we've recently started introducing PEP 484 / MyPy annotations, a compile-time layer that lets us add optional static typechecking to our codebase. This leads to files that have some statically-typed lines, and some lines that are not statically-typed.
It would be nice to have a second coverage column in our code reviews (in addition to the test coverage column) to track whether or not something is statically typed.
Other potential usecases I can think of for >1 coverage column:
- A similar use case can be applied to TypeScript, which is another partially-statically-checked environment
- Splitting up "is this line covered by unit tests or integration tests?"
- For cross-platform libraries, it would be great to have, for instance, "is this covered in Win32 tests?" or "is this covered in OSX tests?" columns
You can sort of get an idea for what the type coverage column would be used for based off this sample:
(This is a real HTML report generated by MyPy and would be trivial to convert into the N-U-C style that ArcanistUnitTestResult setCoverage() uses).
typed_function is typed because it has a PEP 484-comatible # type: ... comment. It takes in an int, and outputs a boolean.
untyped_function is untyped because it doesn't have the # type: ... comment.
main_fn is straightforward until we reach line 12 - here, since we call into an untyped function, the return type is uncertain; hence 12, 13 and 14 are marked as 'untyped' (red).
The crux of this request is that I would like to be able to display this data in Arcanist in addition to the existing code coverage column, as (poorly) mocked up here:
(The first column being "is this line covered in a test?," the second column being "is this line completely typechecked?" Colors don't have to be customizable, it's just for readability.)