In .NET(C#) is there any advantage/disadvantage to go with debug/release build for unit testing?
Which target configuration do you usually use for unit testing on a build server? Does it matter?
What about code coverage (for this one I'm guessing debug versions are needed).
I'd recommend running the release code. For a couple of reasons.
1) It is the code that the customers will be using.
2) Some code has special debug conditionals that will produce differences between the debug and release builds.
You must test the code the way it will ultimately run on the client's machine. In most sane deployment scenarios that will be code compiled in the Release configuration.
I would use release build when possible, to get everything as close to the final product as possible.
There are small differences between debug mode and release mode that normally only make a difference for performance, but not result. However, if there is some timing problems with the code they may only show in release mode, so you could take the opportunity to possibly catch those.
Despite most people obviously favour to unit test the release code, I wonder whether the debug build might uncover more errors, though. (I might be wrong)
E.g. afaik in VS debug code, uninitialized variables are forced to some awful value instead of being 0 "by accident". Maybe in .NET it does not make a big difference, but for me, doing mainly algorithmic core code in C++, this can be crucial.
I look forward to any enlightening comments ;).
It is easier (for me) to get to the root of an exception when testing debug code.
Just adding another reason to test in release mode. Some CI services (Appveyor) will fail the build if it comes across a Debug.WriteLine() call, even though the test itself is green.
We are running both, Debug + Release.
We output a separate tests results xml for each build.
Sometimes there are errors in Debug only, and sometimes in Release only, you want to catch them all ASAP.
Good luck!
Related
We have a situation where a piece of code we've written fails against a test instance of our database because of work yet undone in the database itself. (It's a patching issue on an AS/400 that is completely out of our control) We have to move forward with development and can using a hack for the code in question. We need to make sure that this hack never makes it into the production environment and were wondering if there was a way to make code build correctly when compiling for the Debug configuration but fail with a compiler error when the Release configuration is being built? I've started looking into the build configuration but have yet to find a good approach. Any ideas would be appreciated.
We're using VS 2008, C#, .Net 3.5
Use compiler directives like this:
#if !DEBUG
#error Must not make it into production
#endif
Ideally you would like to add a more complete comment describing why you can't let the hack go into production, detailing the steps or cases in your issue tracker that needs to be completed before it is safe, etc. etc.
How can I run the current game inside the Unity editor in debug mode - as in preprocessor variable DEBUG will be true/enabled for scripts. I normally have a lot of:
#if DEBUG
dostuffonlyindebuglikegetalotofmoneyingame();
#else
// release mode
#endif
scattered around my projects. Using Unity 4.6 RC3.
You can have global #defines with one of these methods:
build settings, per platform
also available via build script:
PlayerSettings.SetScriptingDefineSymbolsForGroup
Global Custom Defines
For debug, maybe a check for UNITY_EDITOR is enough?
I found this:
http://docs.unity3d.com/460/Documentation/ScriptReference/Debug-isDebugBuild.html
Not sure yet but it seems not very good because:
As this is a runtime check, it would probably get debug code into release builds... affecting performance as well as stability and your reputation ;-)
The only supported mode in the Unity "Game" mode is the Debug one. This really sucks. Deploying to devices to test release builds just takes too long time because deployment is SLOW, at least on my box. :-(
Any #if DEBUG etc you wrote so far can't be used. You would have to replace that with the runtime calls Debug.isDebugBuild ... not pretty.
Not sure if Debug.isDebugBuild is removed on release builds or not... if not, Unity sucks :-)
That said, this might be the only option... poor us.
I have a component which can be referenced in some projects (for example, Component.dll). I publish it, of course, in release mode.
In another project (for example, Project.exe) I reference Component.dll.
If I build Project.exe in Debug mode, is there a way to find out about that in my Component.dll library?
To clarify more: if I have a class and a method named Test within Component.dll. Can I do something like:
public void Test(){
if(Debug.IsInDebugMode)
...
}
Keep in mind that Component.dll is built in release mode.
Whether your code is built in Release or Debug mode doesn't matter a great deal. The generated IL is very nearly the same. The Debug version will have an attribute that the jitter uses to set compilation defaults, that attribute is missing in yours. The next thing that matters is exactly how you debug or run your application. The setting that's important is Tools + Options, Debugging, General, "Suppress JIT optimization on module load". It is ticked by default.
Which now makes it matter whether your app gets started by a debugger or not. That's easy to find out, use the System.Diagnostics.Debugger.IsAttached property. When false, the machine code generated from your IL is going to be optimized by the jitter. A degenerate case is attaching a debugger after the code got started. Kinda important that this doesn't make any difference to you btw.
I think I know what a build is. But I am not sure. My definition of a build is another word for saying compiled application. Can someone please tell me what exactly a build is. And why do people ask for 3 types of builds. Such as Debug Build, Profile Build and a Release Build. What are the differences.
[edit]
the types of builds
Have a look at Visual Studio Debug and Release Modes
Release Mode
When an assembly is built in release mode, the compiler performs all available optimisations to ensure that the outputted executables and libraries execute as efficiently as possible. This mode should be used for completed and tested software that is to be released to end-users. The drawback of release mode is that whilst the generated code is usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is compiled in debug mode, additional symbolic information is embedded and the code is not optimised. This means that the output of the compiler is generally larger, slower and less efficient. However, a debugger can be attached to the running program to allow the code to be stepped through whilst monitoring the values of internal variables.
A build means basically doing a set of tasks to make your program. The main components of a typical build is compiling and linking.
More specifically a build can contain compiling, linking, setting version numbers, copying outputs to some location, creating an installer and anything else.
When people say debug or release build or etc., they may have different settings defined for each. For example in a debug build you will create program database files for debugging.
A build does not have to include only compiled and linked targets. Usually there is at least one of those, but a "build" could also include creating plain-text or binary files, moving images, sounds, and other files into the correct places to be accessed by the file, or any other operation that needs to be performed for the application to run.
The multiple types of builds are made to target different "audiences", if you will. For instance, and end-user does not need to collect information about what functions were called or how many times and exception was raised, or any other diagnostic info (though that information is valuable to developers). Usually the final "release" build is made to be fast and small, and not load the user down with extras like that.
I'm working on a demo about collision detection. (Some of the code for this is detailed here.) In Debug mode, it works fine. In Release mode, it's faster, but the collision detection is REALLY messed up. Objects to bounce off nothing, or seem be oddly lightly effected by gravity. Some objects explode, as if they have collided with the special explosive objects, even though none of those objects exist.
So... what does Visual Studio change between Release and Debug mode that causes this problem? (I'm using VS Pro 2008.)
Mysteriously, Release mode had been working for plenty of development. It just recently stopped.
My psychic powers are not great, and it is hard to tell what is going on without actually debugging it. But here's a guess. The issue I discuss here:
Why does this floating-point calculation give different results on different machines?
applies not just to "cross machine" but also to "debug vs release". It is not only possible but likely that the release version of your program is using higher precision math than your debug version. If you have floating point bugs in there then it is entirely possible that just by sheer bad luck you are hitting the bugs only in the higher-precision release version and not in the lower-precision debug version.
Why the difference? Because in the unoptimized version the C# compiler frequently generates code for temporary values as though they were local variables; the jitter then actually allocates temporary locals on the stack, and writes the temporary values from the registers to the locals. Then when it needs them, it reads them back into registers from the temporaries. That journey can cause the value that was in the high-precision register to be truncated to mere 64 bit precision, losing bits of precision.
In the optimized version the C# compiler and the jitter work harder to keep everything in registers all the time, because obviously that is faster and higher precision, though harder to debug.
Good luck. Bugs that only repro in release mode are a total pain.
First, any #if(DEBUG) or #if(RELEASE) pragmas are entered. You may have code in one or the other that should or shouldn't be called, so search for those.
Beyond that, by default Release builds are set to "optimize code", while Debug isn't. Try changing that setting in your release configuration (Project > Properties > Build > "Optimize code") and seeing if that solves the problem.
With debug mode, there is a define in place, (you can confirm this by checking the 'Build Options' when you right click on the solution and select 'Properties' which if used, you can issue the trace calls. In release mode, the define is removed and hence no debugging information is used. If you were to debug that release code, the debugger will not be able to tell what line (original code) it was on even if you specified the location of the source as the code is optimized.
As for your situation, maybe by clearing out the intermediate build files in the release directory or remove the .suo file found in the solution directory might help.
Hope this helps,
Best regards,
Tom.