Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

x64|Debug with solutions dependencies
Adronius
#1 Posted : Sunday, December 14, 2014 5:13:08 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/14/2014(UTC)
Posts: 1
Location: Slovakia

Hello,

How should I configure NCrunch for following use case:

Multiple solutions (.sln) dependend among each other.
x64
Debug
One solution can contains about 30-50 projects (about half of them are test projects)
Application consists of more then 30 solutions.
All solutions' projects are copied while building to \bin\x64\Debug directory that is located next to solution directories.

I would like to use NCrunch for TDD - working on project A inside solution S and write tests in project B (inside same solution S).
Remco
#2 Posted : Sunday, December 14, 2014 8:21:51 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi, thanks for posting!

NCrunch uses a solution as a definition for its scope, so the results on this will depend upon how your solutions are arranged and the manner in which they depend on each other.

If the projects are referencing each other using assembly references, then you'll need to turn on the infer project references using assembly name setting to ensure NCrunch can properly identify inter-project references inside the solutions.

If the projects are referencing each other between solutions using project references, NCrunch should automatically resolve these to build super-sets of the referenced areas of the application ... in practice this will make your solution larger according to NCrunch than it would be as opened inside the IDE, but it will work.

Because NCrunch will not share code coverage or test results across solutions, it would be best to try and split the solutions up so that they represent different functional areas of the application with their individual test projects. You would want to avoid having a single solution for test projects, then another solution for production projects, as NCrunch would become reliant on manual builds and wouldn't show code coverage results over your production code (basically, it wouldn't work).

Placing all projects inside a master solution should allow NCrunch to work normally and aggregate code coverage for all projects at once. It's hard to guarantee the performance of this, however, as NCrunch hasn't yet been designed to handle 900 projects inside one solution.

The build output location of individual projects shouldn't matter as NCrunch will arrange the project workspaces to compensate for this.

Considering the size of your application, I would recommend taking a staged approach to introducing NCrunch to avoid spending stressed hours in 'compatibility hell'. NCrunch does introduce some new constraints on how tests are run, and massive solutions with a long history of development without these constraints can sometimes take some effort to iron out. Ignoring all tests to start with and focusing on certain areas of the application should allow you to introduce the product without taking too much time out of your daily work.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.036 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download