Hacker News Reader

Comment by gmueckl | Hacker News Reader

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.

View on HN

> 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.

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.

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.

There is also composibility: ie make public components and compose them in public, use private as little as possible.

True, just that when you make the pieces too small you can get into component spaghetti as well.

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.

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.

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.

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).

> 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.

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.

Reply on news.ycombinator.com