Writing Complex String Literals
If you know Python, you are familiar with its superior string literal syntax. Basically, you can write complex strings inside your code with little effort.
Most languages don’t have features quite like this. While C# has the verbatim (@) literals which make things a little easier, they still can’t be multiline and they can’t contain quotation marks. Basically, you cannot just paste in some string and expect it to be correct. If you need string data, it is usually easier to load it in from a file. However, there is a third option, as Lars Thorup describes in this article. The idea is to write comments and then parse the actual code file afterwards. Sounds strange? Well, it can be quite useful, especially for unit testing.
On a related note, the website for Mutual Satellites, the project that I worked on while I was with BestBrains, is up. This project is very exciting and I am looking very much forward to seeing it released.
Edit: As Thomas Eyde pointed out to me, verbatim literals can in fact be multiline.
July 23rd, 2006 at 12:35 am
C# strings with @ can be multiline. But you’re right about they can’t contain quotation marks.
July 23rd, 2006 at 8:03 am
Hi Thomas,
you are right - I did not realize this. Thank you
November 23rd, 2006 at 4:55 pm
you should not that the method described by Lars Thorup does not work in release builds, which in my opinion makes it useless
November 23rd, 2006 at 5:52 pm
Hi Olav,
right, it doesn’t work unless the source code is available which causes some obvious limitations. However, for unit testing the concept works quite fine.
November 24th, 2006 at 9:01 am
Kristian,
it doesn’t work if the code is optimized. Then the stack/frame stuff is not reliable.
Check the remarks section here http://msdn2.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx .
I think unit testing of optimized code is important as well.
November 26th, 2006 at 11:19 pm
Hi Kristian and Olav.
The method described works regardless of whether the source code is available. It relies on auto-generating an xml documentation file.
Regarding release builds — I think I know what Olav is doing, but correct me if I’m wrong. The method does actually work in release, but you have to keep a few things in mind. As you pointed out, an optimized stack is a problem (at least for the implementation we came up with). To overcome that issue I see two options.
Introduce [MethodImpl(MethodImplOptions.NoInlining)] in your code, to ensure that methods are not inlined, thus making the stack layout predictable.
Or (maybe even better?), don’t build your tests in release config. Instead, build your app. code in debug and release, and your test code in debug only. Of course you can still run your debug tests against both debug and release versions of your app.
Using the last approach will give you a predictable stack, and hey… Release config means that the executable should be optimized using inlining, stripping debug info etc. Why would you ever compile your tests without debugging info?
I agree that most people builds the app code in two configurations, and they usually do the same with the test code. But I honestly think that instead of running release tests against a release app, what you really want is to run debug tests against a release config of your app.
Just my two cents…