0

Using: MSTest / CppUnit / TFS2015 / VS2013 / C++

I'm debugging a test that runs fine locally and fails on the build machine (which I don't have access to). This morning I sat down and was presented with almost all of my tests passing -- except one. The test happens to be comparing two rather large strings and the (usually) very helpful Assert failed. Expected:<... never made it to the Actual:<... part because the string was too long. It's just a simple: Assert::AreEqual(expectedStr, actualStr);.

Right now my workaround is to write a file to a network path that I have access to from within the test (which is already an integration type test luckily -- but still...). Oh -- and did I mention that I have to run a build that will take 40 minutes even if I set Clean Workspace to None in my build process parameters to even get the test to run? That's a whole other question for another post =/.

Is there a way to look at the full results of a test assertion failure (without, for example, a string comparison being cut off)? A test run log file maybe?

PerryC
  • 1,233
  • 2
  • 12
  • 28
  • Are you using XAML build or vNext build? How do you use MSTest during TFS build? How do you configure build definition? – Cece Dong - MSFT Feb 29 '16 at 07:55
  • Those are all good questions but I can't answer due to work restrictions -- not to mention the short answer is...way too complicated for a comment ;). I accepted your answer as the most relevant (and only) solution. Thanks. – PerryC Feb 29 '16 at 14:52

1 Answers1

1

According to your description, you want to express assertion failure messages in C++. Check this case may help you:

" A common solution for this problem is to create an assert macro. For an example see this question. The final form of their macro in that answer was the following:

#define dbgassert(EX,...) \
  (void)((EX) || (realdbgassert (#EX, __FILE__, __LINE__, ## __VA_ARGS__),0))

In your case, the realdbgassert would be a function that prints any relevant information to stderr or other output console, and then calls the assert function itself. Depending on how much information you want, you could also do a stack dump, or log any other relevant information that will help you identify the issue. However, it can be as simple as passing a printf-esque format string, and relevant parameter value(s).

Note that if you compiler doesn't support variadic macros, you can create macros that take a specific number of parameters instead. This is slightly more cumbersome, but an option if your compiler lacks the support, eg:

#define dbgassert0(EX) \ ...
#define dbgassert1(EX,p0) \ ...
#define dbgassert2(EX,p0,p1) \ ...

"

Community
  • 1
  • 1
Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39