4 ms·

Per function, not overall. A function with more lines of code is doing more, and so is harder to test

sidlls 9y ago
It isn't harder to test, necessarily. It's harder to unit-test. The distinction is important. Perhaps a single test that TDD people might call an "integration test" suffices for that function. Often it does, in fact.
- AdeptusAquinas 9y ago
  An integration test isn't a test for a function. Its a test of the system as a whole. On a per function level, more code in a function makes it harder to test, whether you are unit testing it or somehow manually testing it.
  - sidlls 9y ago
    It seems agreeing on what a "unit" is is elusive. If a function calls another function, for example, testing the caller without mocking the callee, I'm told often, is not truly a unit test.
spc476 9y ago
No, a function can be long but have a low cyclomatic complexity score [1] (being a list of do_this(), do_that(), do_somethingelse(), etc) while a short function can have a higher cyclomatic complexity score (lots of fiddly logic). [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity
- Dylan16807 9y ago
  You could deliberately do that. But most of the time length and complexity correlate. More importantly, when you're splitting up functions to make them testable, you're very much reducing complexity and length in tandem.
  - sidlls 9y ago
    Splitting up functions just to make them testable is like a code smell, in my experience. It has correlated highly with cultish adherence to testing for the sake of testing rather than to achieve an engineering or quality goal. It might be reducing "cyclomatic complexity" but not necessarily overall complexity. Often the opposite is true: reduced locality imposes its own costs in maintenance and efficiency for example.
    - vikiomega9 9y ago
      I don't think that makes sense, if I had a longish method or a task that could be decomposed into smaller pieces to clearly identify what's happening I would prefer to break it up and test those pieces if it made sense. Obviously this depends on how you do it. DDD talks about this in terms of services and such which might be what your long function really is. In which case you _do_ have to test this large chunk of logic.

It isn't harder to test, necessarily. It's harder to unit-test. The distinction is important. Perhaps a single test that TDD people might call an "integration test" suffices for that function. Often it does, in fact.

AdeptusAquinas 9y ago
An integration test isn't a test for a function. Its a test of the system as a whole. On a per function level, more code in a function makes it harder to test, whether you are unit testing it or somehow manually testing it.
- sidlls 9y ago
  It seems agreeing on what a "unit" is is elusive. If a function calls another function, for example, testing the caller without mocking the callee, I'm told often, is not truly a unit test.

spc476 9y ago

No, a function can be long but have a low cyclomatic complexity score [1] (being a list of do_this(), do_that(), do_somethingelse(), etc) while a short function can have a higher cyclomatic complexity score (lots of fiddly logic). [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity

Dylan16807 9y ago
You could deliberately do that. But most of the time length and complexity correlate. More importantly, when you're splitting up functions to make them testable, you're very much reducing complexity and length in tandem.
- sidlls 9y ago
  Splitting up functions just to make them testable is like a code smell, in my experience. It has correlated highly with cultish adherence to testing for the sake of testing rather than to achieve an engineering or quality goal. It might be reducing "cyclomatic complexity" but not necessarily overall complexity. Often the opposite is true: reduced locality imposes its own costs in maintenance and efficiency for example.
  - vikiomega9 9y ago
    I don't think that makes sense, if I had a longish method or a task that could be decomposed into smaller pieces to clearly identify what's happening I would prefer to break it up and test those pieces if it made sense. Obviously this depends on how you do it. DDD talks about this in terms of services and such which might be what your long function really is. In which case you _do_ have to test this large chunk of logic.