4 ms·

In some languages / project structures you need a way for internal components to connect that happens to be "public" but is not meant for public use. I see thi

• gmueckl 8y ago
  C++ and C# have the same kind of problem: except for the iffy freind declaration in C++ there is no way in the language to denote that some method is bot meant for use in other modules. C# has the internal scope for each assembly, but this breaks in combination with unit tests placed in seperate testing assemblies. Generally, proper unit testing is at odds with strict scope restrictions in the tested code. I guess we need more allowances fornunitbtesting at the language level to fix that. E.g. allow testing code to be marked as such and ignore that certain things are declared private, but in turn only allow it to be run in a testing context, but not regular builds, to prevent abuse.
  • flukus 8y ago
    > C# has the internal scope for each assembly, but this breaks in combination with unit tests placed in seperate testing assemblies. This is a limitation imposed by the IDE, not the language. There's nothing stopping you from compiling code and tests into the same dll that you unit test. Likewise there is no need to separate code from the tests (apart from different files), they can simply not be included in release builds. Source layout structure does not have to be a 1 to 1 mapping of the output structure.
    • gmueckl 8y ago
      Not keeping tests separate from the tested code can lead to chaos in the long term. It provides an incentive to blur the lines in inappropriate ways, e.g. by adding helper code for tests to the code under test etc.
  • pjmlp 8y ago
    > C# has the internal scope for each assembly, but this breaks in combination with unit tests placed in seperate testing assemblies. That is what [assembly: InternalsVisibleTo()] is for.
    • gmueckl 8y ago
      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.