Most common is, to have a separate DLL for sut and tests; next common is, to
use [InternalsVisibleTo(".. tests.."] in assembly info of the sut, but that
only works with strong naming.
Being able to test internal methods by just compiling tests and sut together
seems like a good option. It has one caveat, though: the tests are not run
against the actual artifact. So when for example the sut scans assemblies using
reflection, which is quite popular these days, the test-sut and the real sut
may behave differently.
We also have to think how this would be in VS. I'd prefer to have all sources
in my root and then exclude /Test/** for the main compile.
_
Lars
Am 08.12.2011 um 00:48 schrieb Brett Porter:
>
> On 08/12/2011, at 2:37 AM, Matthias Wessendorf wrote:
>
>> I was wondering if others would see some value in modifying the "test
>> plugin" to include the "source" automatically (in the
>> build-test-sources folder) to allow serious unit testing of internal
>> classes etc. :-)
>> (of course this could be tweaked/triggered by a (configuration) parameter)
>
>
> How common do you think this would be? Is it something .NET developers (aside
> from NPanday) would often do?
>
> - Brett
>
> --
> Brett Porter
> [email protected]
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
