6 ms·

Your comment sounds like TDD religion to me. "Deciding what a unit is" isn't the hard part. The hard part is finding the units that benefit from unit tests (an

by hnfong 4y ago

Your comment sounds like TDD religion to me. "Deciding what a unit is" isn't the hard part. The hard part is finding the units that benefit from unit tests (and convincing other religious people about this, as I am trying to now, which in this case - not many). The Linux system calls are "deceptively simple". Simple to test, right? How complicated can say `write(2)` be? But if you actually tried doing it, I'd be surprised if you can write reliable "unit" tests beyond writing to /dev/null. The practical way to test system calls are to test it with real world usage. Unit tests here might catch some problems, but the vast majority of kernel bugs aren't those that can be caught with unit tests. (If they're bad enough, the bug will cause the OS to crash before it completes booting, no unit tests needed.) The more subtle bugs are often hard to reproduce, only happens in certain loads and hardware. As to your final edit-to-add: you're joking right? Like Linux syscalls need more documentation. POSIX (I'm aware this is not exactly Linux documentation, but still) was a spec literally before Linux was started. edit PS: https://tenor.com/view/unittest-unit-test-gif-10813141 https://tenor.com/view/unittest-unit-test-gif-10813141

makapuf 4y ago
I don't know how many LOC you could trigger with a write. Including all drivers, filesystems , ..., perhaps millions. Hardly a unit test. And then, a driver is difficult to unit test. BUT some parts of the kernel could use unit tests. The thing is, they don't and the usage of the kernel shows that they would be triggered by usage, but it wouldn't harm.
Izkata 4y ago
> Your comment sounds like TDD religion to me. GP is using the original definition of unit test, GGP is using the religious implementation-level definition TDD advocates have come up with. From GGP: > but integration and behaviour tests for the external interface/API are more important than exercising an internal implementation detail. They call this an integration test, but by the original definition, testing the interface is a unit test. An integration test is how multiple units interact with each other. Testing the implementation details is what TDD advocates have turned unit testing into, by changing the definition of "unit" from semantics (a self-contained module that does one thing from the business perspective) to syntax (a function). > edit PS: https://tenor.com/view/unittest-unit-test-gif-10813141 https://tenor.com/view/unittest-unit-test-gif-10813141 Seems like you agree with the original definition. The TDD version of this GIF would be a test for each part that makes up the handle (the implementation details instead of the interface).
- hnfong 4y ago
  The semantics doesn't really matter either way. The comment I originally replied to basically implied the whole Linux kernel is one "unit" (or at least each kernel syscall is one unit... which isn't much difference due to large interdependencies between them). Using that definition, that's just basically saying "the kernel can benefit from ... tests". Of course the Linux kernel doesn't have "TDD-religion unit tests", but there's already more than enough "tests" for the Linux kernel, and there's more than enough benchmark tests for the Linux kernel (for the optimization argument). They're just not "unit" tests in any meaningful way. From the pedantic side of things, the original comment said "(TDD-religion) unit tests are overrated", then the reply was either "no they're not", or "no, unit tests (as originally defined) are not overrated". The latter is somewhat inconsistent with the "hard disagree", so either they were confused as to which definition they wanted, or cherry picked properties from both unit testing regimes.

by hnfong 4y ago

makapuf 4y ago

I don't know how many LOC you could trigger with a write. Including all drivers, filesystems , ..., perhaps millions. Hardly a unit test. And then, a driver is difficult to unit test. BUT some parts of the kernel could use unit tests. The thing is, they don't and the usage of the kernel shows that they would be triggered by usage, but it wouldn't harm.

Izkata 4y ago

> Your comment sounds like TDD religion to me. GP is using the original definition of unit test, GGP is using the religious implementation-level definition TDD advocates have come up with. From GGP: > but integration and behaviour tests for the external interface/API are more important than exercising an internal implementation detail. They call this an integration test, but by the original definition, testing the interface is a unit test. An integration test is how multiple units interact with each other. Testing the implementation details is what TDD advocates have turned unit testing into, by changing the definition of "unit" from semantics (a self-contained module that does one thing from the business perspective) to syntax (a function). > edit PS: https://tenor.com/view/unittest-unit-test-gif-10813141 https://tenor.com/view/unittest-unit-test-gif-10813141 Seems like you agree with the original definition. The TDD version of this GIF would be a test for each part that makes up the handle (the implementation details instead of the interface).

hnfong 4y ago
The semantics doesn't really matter either way. The comment I originally replied to basically implied the whole Linux kernel is one "unit" (or at least each kernel syscall is one unit... which isn't much difference due to large interdependencies between them). Using that definition, that's just basically saying "the kernel can benefit from ... tests". Of course the Linux kernel doesn't have "TDD-religion unit tests", but there's already more than enough "tests" for the Linux kernel, and there's more than enough benchmark tests for the Linux kernel (for the optimization argument). They're just not "unit" tests in any meaningful way. From the pedantic side of things, the original comment said "(TDD-religion) unit tests are overrated", then the reply was either "no they're not", or "no, unit tests (as originally defined) are not overrated". The latter is somewhat inconsistent with the "hard disagree", so either they were confused as to which definition they wanted, or cherry picked properties from both unit testing regimes.