That's the absolutely wrong way to test a function. You want to test a function so _as the implementation changes, the same output follows the same inputs_.
Counterexample: I might refactor that function without those code paths (e.g. write `x*sign(x)` instead). Do I need only one test now?
Morale: DO NOT TEST IMPLEMENTATIONS
Of course, hitting each line with a single test doesn’t guarantee your tests are “sufficient,” but pragmatically it seems like a reasonably good and easy to understand starting point.
Tests derived this way will still be useful if the implementation were changed to something that didn't branch.
I suspect though that we shouldn't get too stuck on the testing thing. The author only asked the question to introduce thinking about how to abstract expectations behviour out of concrete code. Test generation is only one of the uses he cites.
If you can look at it and see the code is needed, then you are clearly lacking a test that shows why it is needed. You can let both ends inform the next step.