For c# codebase, why are tests compiled into the library itself?

[Sid Shetye]

I noticed that if currently ALL the tests for Bouncy Castle are compiled
into the library DLL itself (instead of a separate library test .DLL). This
can be an unnecessary drain for projects that use/include the BouncyCastle
library (crypto.dll) since the consuming application doesn't really care
about the tests and all the static test vectors it brings.



I quickly extracted out the tests

Before:

crypto.dll: 5.4 MB

crypto-test.exe: 16KB



After:

crypto.dll : 1.4 MB (380% / 3.8x better)

crypto-test.exe: 4MB



The changes are actually quite trivial:

1. Move entire \test\ folder from 'crypto' project into 'crypto-test'
project (drag drop in VS2012, it will fix the build include .cs file list in
both projects)

2. Right click 'crypto-test' -> properties -> application tab ->
startup object -> choose crypto_test.CryptoTest (to resolve multiple Main()
entry points)

3. Inside src\util\platform.cs replace all 'internal' protection
levels with 'public' protection levels

4. Removed references to nunit* in crypto project

5. Added the above nunit* references to crypto-test project

6. Rebuild both projects / solution



Question: Apart from insufficient time (which I totally get), is there
another reason these have been included in the library itself? Some tests do
fail because they are hardcoded to expect embedded test data inside the
library .dll and then fetch it via
Assembly.GetExecutingAssembly().GetManifestResourceStream(fullName);
//fullname=filename of resource embedded into .dll eg:
"masterlist-content.data"). This is more of a test design issue than
anything else.



Peter, side question: Is there any plan to migrate from CVS to GIT? IMHO GIT

CVS for branching and distributed development; plus GitHub amplifies that

GIT advantage too. Just asking.



Thanks

Sid

[Peter Dettman]

Well, it's sort of the way it fell into my lap oh so many years ago...
but some points:

- The release builds are actually done using NAnt at the command line
(compile-release/dist targets), and the tests are excluded from that. I
only really use the project files for development work.

- The tests are intended to have access to some things scoped as
'internal', though over time I've tried to reduce it, so I'm not sure if
it's an issue so much these days. If it's just Platform.cs as you say,
this may be easier than I thought.

- CVS->git is being discussed, but I can't offer you a timeline. I'm
fairly keen myself, as I see it as a way to lower the barriers for
getting other more knowledgable .NET developers to give me some help
with the build system, NuGet, and perhaps monitoring/testing things for
particular platforms (Mono, .NET CF, Silverlight, hopefully Portable
Class Library as of 1.8).

Yes, time is certainly in short supply.

Regards,
Pete Dettman

Post by Sid Shetye
I noticed that if currently ALL the tests for Bouncy Castle are
compiled into the library DLL itself (instead of a separate library
test .DLL). This can be an unnecessary drain for projects that
use/include the BouncyCastle library (crypto.dll) since the consuming
application doesn't really care about the tests and all the static
test vectors it brings.
I quickly extracted out the tests
crypto.dll: 5.4 MB
crypto-test.exe: 16KB
crypto.dll : 1.4 MB (380% / 3.8x better)
crypto-test.exe: 4MB
1.Move entire \test\ folder from 'crypto' project into 'crypto-test'
project (drag drop in VS2012, it will fix the build include .cs file
list in both projects)
2.Right click 'crypto-test' -> properties -> application tab ->
startup object -> choose crypto_test.CryptoTest (to resolve multiple
Main() entry points)
3.Inside src\util\platform.cs replace all 'internal' protection levels
with 'public' protection levels
4.Removed references to nunit* in crypto project
5.Added the above nunit* references to crypto-test project
6.Rebuild both projects / solution
Question: Apart from insufficient time (which I totally get), is there
another reason these have been included in the library itself? Some
tests do fail because they are hardcoded to expect embedded test data
inside the library .dll and then fetch it via
Assembly.GetExecutingAssembly().GetManifestResourceStream(fullName);//fullname=filename
of resource embedded into .dll eg: "masterlist-content.data"). This is
more of a test design issue than anything else.
Peter, side question: Is there any plan to migrate from CVS to GIT?
IMHO GIT > CVS for branching and distributed development; plus GitHub
amplifies that GIT advantage too. Just asking.
Thanks
Sid