3 ms·

This only covers a small part of the problem. Things that should be private and requite separate yesting are atill required to be more visible than they are sup

This only covers a small part of the problem. Things that should be private and requite separate yesting are atill required to be more visible than they are supposed to.

pjmlp 8y ago
I have the opinion that is the job of functional tests anyway. Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.
- whatsstolat 8y ago
  There is also composibility: ie make public components and compose them in public, use private as little as possible.
  - pjmlp 8y ago
    True, just that when you make the pieces too small you can get into component spaghetti as well.
    - gmueckl 8y ago
      Yup. And you can completely ruin performance, if that is something you need (I do in some of my code). Abstractions in the wrong places can hurt.
- gmueckl 8y ago
  This simply cannot work in many cases. It is quite unrealistic to test complex logic that is hidden behind a narrow interface completely. You are hit with the full combinatorial complexity of what is behind that interface, even if might consist of independent parts internally. If you can test these parts independently, the number of required tests is a fraction of what a black box approach requires. Another situation is checking numerical code for correctness and accuracy. There it is extremely advantageous to have testable small functions that map to individual mathematical expressions. But these are again implementation details that need to be hidden behind interfaces.
  - pjmlp 8y ago
    That leads to program for unit tests, exposing parts that shouldn't be visible in first place. Your numerical code example can be achieved with an Assembly of internal functions/methods, exposed only to the implementation and unit tests. Of course, this is easy to do in a greenfield project from the start, not so easy on legacy code.
    - gmueckl 8y ago
      Your first statement is exactly what I've arrived at. It's just not avoidable in general. I have to clarify that I'm not fixated on C#. Sure, you could create a helper assembly in .NET that is a mess of essentially of disembodied functions for computing every slightly more complex function that happens to be in your program. But this breaks OOD. In C/C++ you can't do quite the same. The best you could do there is break OOD and try to hide these global functions by using private headers (which are ugly in their own ways).

This only covers a small part of the problem. Things that should be private and requite separate yesting are atill required to be more visible than they are supposed to.

pjmlp 8y ago

I have the opinion that is the job of functional tests anyway. Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.

whatsstolat 8y ago
There is also composibility: ie make public components and compose them in public, use private as little as possible.
- pjmlp 8y ago
  True, just that when you make the pieces too small you can get into component spaghetti as well.
  - gmueckl 8y ago
    Yup. And you can completely ruin performance, if that is something you need (I do in some of my code). Abstractions in the wrong places can hurt.
gmueckl 8y ago
This simply cannot work in many cases. It is quite unrealistic to test complex logic that is hidden behind a narrow interface completely. You are hit with the full combinatorial complexity of what is behind that interface, even if might consist of independent parts internally. If you can test these parts independently, the number of required tests is a fraction of what a black box approach requires. Another situation is checking numerical code for correctness and accuracy. There it is extremely advantageous to have testable small functions that map to individual mathematical expressions. But these are again implementation details that need to be hidden behind interfaces.
- pjmlp 8y ago
  That leads to program for unit tests, exposing parts that shouldn't be visible in first place. Your numerical code example can be achieved with an Assembly of internal functions/methods, exposed only to the implementation and unit tests. Of course, this is easy to do in a greenfield project from the start, not so easy on legacy code.
  - gmueckl 8y ago
    Your first statement is exactly what I've arrived at. It's just not avoidable in general. I have to clarify that I'm not fixated on C#. Sure, you could create a helper assembly in .NET that is a mess of essentially of disembodied functions for computing every slightly more complex function that happens to be in your program. But this breaks OOD. In C/C++ you can't do quite the same. The best you could do there is break OOD and try to hide these global functions by using private headers (which are ugly in their own ways).