On my way into trouble for this iteration, I created a new project in Visual Studio intended to be the beginning of the real deal. During it's setup, it asked me what testing framework I wanted to use and offered me mbUnit. I chose it and went to work. I created my first bit of nHibernate (ouch!) and made a test to try it out. It failed and sucked up another horrifying amount of time and pain.
I found a small tutorial that just did a tautological unit test (assert a=a). One step explained that I should see the test in Test View. Nope. Nada. Another painful experience trying to make it work. Gave up. Wrote an inquiry to the mbUnit group on google. A nice guy got back pretty quick. He pointed me to a page that looked promising but was long. Since I was in the middle of something else (nHibernate, my new bete noir!), I tabled it for later on.
In my thrashing for nHibernate I, for obscure reasons, decided to make a new project for some reason. While doing it, I noticed that VS offered me, in addition to .NET MVC, an "mbUnit Project." OMG!! I said, Yes, and created one. It didn't look like anything special, so I continued on my Via Dolorosa until I ran out of steam there.
Hoping to salvage something from the day, I looked again at my mbUnit project. I wondered how it was going to know what I wanted to test since it's in an entirely different project from the test target. Let me digress briefly...
During this week's angst, I have come to understand much more about how .NET stuff works. I now know, among other things, where .dll files come from and what they do. They come from a Visual Studio build. I suspect that it is a combination compilation and link process. There is a directory called "bin" that, after I build, gets a filed like, ProjectName.dll. Get a load of that. To get nHibernate and mbUnit going, I had to add a "reference" to their .dll files. Very interesting.
Along the way, I found an explanation about nHibernate that suggested a better file organization (should have done it first but whatever I was learning from at the time got me distracted), ie, a directory specifically for third party software. This seemed like a good enough idea that I paused in my efforts to move things around. That caused me to open the bin directory are really focus. In it, I had put several files for mbU and nH, but lo and behold, there was also, ProjectName.dll. It had also copied the referenced .dll files there as well. Lights went on.
Later, the nHibernate fiasco told me that I needed to have its XML file as an "embedded resource". I did that (to no avail) and realized that must mean that it can pack things into the .dll, as well as put them nearby as references. It also told me that I needed to build explicitly because VS wouldn't automatically detect changes to XML as it (sometimes) does to code.
Cool beans. I am now a reference expert.
Asking myself how mbUnit would know about my real ProjectName, I did two things: 1) added a reference to the ProjectName.dll, even though it was in some other project's directory, and 2) put a using statement that referred to the test target's namespace (using ProjectName.Models) and then instantiated a "TestTarget xxx=new TestTarget();" It had a method that was there for just this purpose and Voila!, I was able to test and will be able to test from now on.
This is killer.