code name

My not-so-humble evaluation of VS tests distinctions from NUnit is (in points on -10 to 10 scale).

• (-4) To run tests, VS launches an entire process which takes no less then 3 seconds to start. If you’re in “F5 hit breakpoint – Shift-F5″ loop, that’s disgusting. NUnit tests can be run in-process by Resharper or TestDriver.NET;
• (-2) GUI that shows where test failed is ugly. You don’t get to failed line on double-click, you first get to test log page. Status and call stack are necessary, but I’d like not to trash my document tabs, I already have enough of them open. You can’t make that kind of windows docked/floating;
• (-1) You got a “public TestContext TestContext;” sticking in your code. You’ll need it only when it comes to testing on data, which doesn’t always happen, even in a data-driven application;
• (-1) It’s a “not invented here” technology, while NUnit was around for years;

Edit: In a moment of madness, I mixed together coverage profiling and unit testing tools. May God and readers forgive my aberration.

Edit2: If you need a half-page kickstart in unit testing techniques, the next post can help.

Did you ever think, what happens if you take a member pointer to a virtual function of a class, and then call it on another instance of derived class (that overrides that member)?

What if you do the same for nonvirtual function?

Here’s a test:

#include <iostream>

class A
{
  public:
  virtual void f() { std::cout << "A::f()\n"; };
  void g() { std::cout << "A::g()\n"; };
};

class B : public A
{
  public:
  virtual void f() { std::cout << "B::f()\n"; };
  void g() { std::cout << "B::g()\n"; };
};

typedef void (A::*VirtualFunctionPointer) ();

int main()
{
  A a;
  B b;
  B* pb = &b;

  VirtualFunctionPointer p = &A::f;
  (pb->*p) ();

  p = &A::g;
  (pb->*p) ();
  return 0;
}

Answer is in comments.

A couple of notes how NOT to use MSBuild.

1. Don’t generate files with AssemblyInfo task. It screws comments, screws InternalsVisibleTo attributes, and whatever else it doesn’t account for.
   Instead: Use
   <FileUpdate Files="@(AssemblyInfoFiles)"
Regex="AssemblyVersion\(".*?"\)\]"
ReplacementText="AssemblyVersion("$(Major).$(Minor).$(Build).$(Revision)")]"
/>
<FileUpdate Files="@(AssemblyInfoFiles)"
Regex="AssemblyFileVersion\(".*?"\)\]"
ReplacementText="AssemblyFileVersion("$(Major).$(Minor).$(Build).$(Revision)")]"
/>
2. Don’t account for TfsXXXX community tasks – it won’t run on VS 2008 with Team Explorer 9.0.
   Instead:  Use <Exec Command=”tf …”>.
   And if you have domain authentication in TFS and don’t run integration under domain user (which happens), you even can’t run tf in cmd-line mode: stupid authentication dialog will pop up.
3. Do not use local files to store version number. You will lose them when moving build to another host, so use only source control-dependent files.
   Might seem evident, but strange how many people miss this.
   So you’ll need to
   <Attrib Files="version.txt" Normal="true" />
4. Per Scott Colestock’s post, “since TfsVersion interrogates the build server’s workspace, and BuildNumberOverrideTarget comes early in the process… you might find that you don’t get the changeset number you expect”.
5. Don’t try to operate on XML node collections with tasks other then Xslt.
   For instance, XmlRead returns a Nodeset only as a string of “;”-joined
   Node.Value-s.
   XmlQuery supports Values property, though I wasn’t able to operate it’s results.
   Instead you can use ReadLinesFromFile (sadly, this will trim the lines).
   My personal choice for not-too-complex XML is… you can guess… yes, FileUpdate.
6. Don’t use FtpUpload. It won’t create folders for you.
   Just <Exec> a ftp…
   By the way, Windows’ ftp.exe client is unable to upload in passive mode. You can download passively, if you issue “LITERAL PASV“, but it won’t help the client.