thinking-out-loud

.NET vs. Java revisited

I received a couple of comments about my recent post on .NET vs. Java, and I thought I would offer a response. Enrique mentioned the issue of having a multiplatform shop, and having to deal with the fact you have multiple platforms. Lucian mentions cost, citing Linux + Java + Eclipse + JBoss as all being free.

Let us approach them in the opposite order. First, on Windows, once you purchase the OS, the application server and .NET SDK are free. There are a couple of free developer tools, including sharpdevelop and a c# plugin for eclipse. Second, you could conceiveable go the Linux+Mono route. Have I ever? No. Do I know any enterprises that are doing that? No. YMMV. At any rate, I don't think that the MS OS price or even that plus the cost of MSDN subscriptions for each developer is going to be the lion's share of the total system cost. Developers are pretty expensive by comparison.

As far as multiplatform enterprises go, yes, you have to do what you have to do. Does that mean that you shouldn't choose .NET when you are on MS? You will either need cross-trained developers or segmented developers. If you are going to throw multiple, existing platforms into the mix, then you probably already have to support more than just .NET and Java. You might have to support RPG on AS/400. The question is just as approachable, and you will probably end up aggregating related services together, and you will probably have picked a future direction for your enterprise already, i.e. you are going to deliver all future software on the XYZ platform using the ABC development stack.

To clarify my intent, I was mostly talking about a developer/designer experience. That is, choose your poison, and then tell how it was. I wasn't talking so much about the overall impact to an architecture or TCO, which I agree are both fair topics.

Google blog search

In case you haven't seen it, google has released their blogsearch engine to the wild. Learn more here, including advanced keywords like:

link:

site:

intitle:

inblogtitle:

inposttitle:

inpostauthor:

blogurl:

It doesn't seem to be all that great yet, but knowing google, it will get better. I wonder whether this will have impact on the content served by google proper.

Visual Studio 2005 RC1 available!

I don't see anyone mentioning this yet, but Visual Studio 2005 release candidate (RC1) is available on MSDN downloads as of 9/12.  The release was announced earlier this month by Soma, but no date was given.  I was getting antsy and decided to go look on MSDN myself.  Oh, and now I see that Soma's announcment has a 9/13 comment stating RC1 availability "since late yesterday"

It looks like SQL Server 2005 RC1 is also out there, released on 9/12.  Good stuff.

Now if my client just had a faster download pipe!

---

Warning Update: Don't go uninstalling the Beta 2 just yet.  This package doesn't seem to include the Team System plug-in, so you don't have access to TFS.

LINQ

Via Tim Ewald. LINQ stands for Language Integrated Query for .NET. TimE provides a link to the main page. Check out the samples page to get an idea of what you can do with LINQ. I completely agree with Tim, MS. Please please please get this out soon. I don't know that I get exactly how it will solve the O/R, O/X, X/R problems -- I can see how it would help. More than that, though, I can see a lot of other uses. If you have ever implemented the visitor pattern, for instance, LINQ has the potential to make you drool.

thinking-out-loud: TestNG - Welcome

One other thing about TestNG that relates well to JUnit NUnit or other unit testing frameworks. I was reading through the list of posts that Cedric listed as motivation to develop testNG. One of the posts discusses the desire to understand what is being tested from the message in the assert.

Two thoughts here: First, the method name ought to be an intention revealing method name, and the asserts should relate to the method only. Second, I have adopted the convention of describing my expectations in the message.

I used to always describe the failure, e.g.

assertEquals("Did not get expected number of whoozits", expectedNumber, actualNumber);

I still like that approach, but these days, I tend to state my expectations in the message. Let's say that I am using xpath to count the number of whoozit nodes in an xml doc. Rather than having something like:

assertEquals("whoozit xpath test failed", expectedNumber, actualNumber);

I have

assertEquals("Expected 4 whoozits", expectedNumber, actualNumber);

That is a pretty lousy example, but try it out for yourself in your tests. I think it works fairly well.

TestNG - Welcome

As I recently mentioned, I have been back in the Java world after a few years of almost exclusively .NET development. The client I am working with had a list of jdk5 bits to look into, and one of the things was "TestNG". I hadn't heard of it, so I did a little googling and ended up at TestNG's site. It is kind of a cross between JUnit and NUnit using JDK5 annotations. Cool.

sofake

I love this site, and I especially love the claim on the site:

"The most professional web design firm in the world."

They apparently did the work on billyharveymusic.com - I like the music, and I love the user experience.

Principles for Test-Driven Development

As I mentioned earlier in a post about TDD with Visual Studio, I recently watched some smart guys at MS preach TDD tips and techniques.  They had some great points so I thought I'd distill them into bullets for future reference.

1) Tests serve as examples of how to use a class or method.  Once used to having tests that show how things work (and that they work), developers start using the key phrase, "Do you have a test for that?"

2) Developer tests (they call them "coder tests") are distinctly different from QA test and should be kept separate.  QA tests target features and treat the system as a black box.  Unit test created by the developer operate at a lower level and test different things.

3) Name your tests carefully.  I'll expand on that and give some of my own guidelines here.

• Name test packages like the package being tested with a suffix.  For example, the "DataAccess" project/package is tested by "DataAccess.Test".
• Name test classes the same as the class under test with the suffix "Test".  For example, the class "PrintManager" is tested by the test class "PrintManagerTest".  This convention makes it easy to find the related class and keeps the class name a noun.
• Name test methods the same as the method being tested with the prefix "Test".  For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()".  This convention keeps the method name a verb that reads as and English phrase.  It's also compatible with NUnit's feature that assumes any method of a test class starting with the word Test is a test method.

4) Write each test before writing the method under test.  This ensures that you don't waste time writing code that isn't going to be tested and used.  It also encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.

5) Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As.  Arrange is variable declaration and initialization.  Act is invoking the code under test.  Assert is using the Assert.* methods to verify that expectations were met.  Following this pattern consistently makes it easy to revisit test code.

6) When writing application code, only write enough code to make a test work.  If you know there should be more code to handle other logic cases, go write the tests for those cases.  This technique prevents gold-plating and ensures that you always have a test for the code you write. 

7) When you find you need to refactor working code, refactor and re-test prior to writing new code.  This technique ensures your refactoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.  I equate this principle to the practice of running all tests in a solution after getting the latest code from the repository and prior to writing anything new.  I don't want to spend time debugging my newly written code under the false assumption that the system wasn't already broken.

I feel the urge to point out that in the webcast they are preaching test-driven development to the point of test-driven analysis & design.  While I know it's the XP way, I disagree the idea that you shouldn't implement the correct long-term design when you know it's appropriate.  In other words, analyzing your problem domain and producing a conceptual model prior to writing code is a good thing.  And, the major benefit of OOP is that your code should reflect the concepts in the problem domain.  So, when your TDD causes you to think, "I need a new class here", refer to your conceptual model and add the right class in the right structure.  Improper inheritance and other kludges along the way just increase the number of iterations and amount of refactoring required to get to your end-goal.  Iteration is good.  Hyper-iteration is a waste.

.NET vs. Java? It's All About Choice

I can't count the number of people in the past few years that have asked me to weigh in on the Java vs. .NET debate. You'll find my answer here, and the answer is simple. It is the only answer I know.

It depends.

Heh.

It does depend, but--for the most part--it is all about choice. In Java, you get a lot of choices. Open source vs. commercial, this platform, that platform; EJB, Pojo; Spring, Struts, Pico, foo, bar, blah blah blah. And therein lies one of the biggest problems with Java -- you have to make choices. And those choices can be non-trivial in light of the intricate version dependencies that can ensue.

With .NET on the other hand, you don't have nearly so many choices most of the time. Most of the time, you eat what Microsoft puts on your plate, and you like it, or you go to bed hungry. Most of the time, though, it is good enough.

And so you can focus on bottom-line, droll things like your business domain. You still have to focus on those things in Java, of course, you just have to after you have selected your platform, container, and so on.

That being said, it sure is nice to have some of the choices you have readily, freely available to you in Java. Like Active MQ.

---

So, given a choice between .NET and Java, I'd rather be doing Ruby.

AppSettings and Visual Studio Test System

Apparently I'm in tester mode these days.  Today I spent the entire day figuring out how to do proper unit testing with Visual Studio 2005's new Test System.  It's integrated with the Visual Studio Team Edition, which my client is using for a variety of small teams where every developer plays just about every role.  Here's a quick overview of the unit testing features and a webcast of some MS dudes pitching test-driven development (TDD) in VS 2005 (more on that soon).

The big buggaboo that consumed my day is the little fact that when a test is executed, the app doesn't run in the bin\Debug directory like normal, but rather in the ~\Local Settings\Application Data\VSEqtDeploymentRoot where ~ is the user's home directory, generally under C:\Documents and Settings\<user name>.  You can change that test run path in VS, but you won't want to point it to your solution folder because it copies all the runtime assemblies into a temp folder there.  Sure, it sounds like a good thing to isolate your tests, but what about config files???

Now, I already had unit tests built for NUnit and found this crafty tool to do  conversions.  But I didn't use it since there were just a few tests so far and I wanted to ingrain all the differences in my fragile little mind.  However, right off the bat I realized that you can't just convert any ole' class library into a VS test library.  First, you have to create a test project from scratch, and then write tests or copy your existing ones in.  (The instructions on the tool just mentioned indicated the same thing.)  I spent a good while trying to hack the solution and project files to no avail. 

Also, in my June or July release of VS 2005, you can't just select Add > New Test from the solution's context menu, either, because it will create a VB.Net project <blech> (unless that's what you really want, of course).  Instead you have to choose Test > New Test from the main menu to get a choice of languages and the option to use the Unit Test Wizard.  The wizard works after you get past it's penchant for reverting back to VB.  I accidentally create a VB test project despite my initial choice of C# and had to delete and re-create, so doulbe check!  It would have been a pain if under source control instead of in my SandBox solution.

So, I finally got a C# test project, copied my NUnit test into it, and made the minor syntax changes to attribution (TestFixture becomes TestClass, Setup becomes TestInitialize, TearDown becomes TestCleanup, and Test become TestMethod - I like these better).  I ran the tests using TestDriven.net's handy context menu option and everything worked.  Then I got ambitious.  Let's use the built in test execution method like they did in the wabcast!

It's actually pretty simple: you just set the test project as the startup project, and run it (F5).  Hmmmm....but every test broke.  And I just ran them with TestDriven.net!  What gives? 

The cool thing about running tests with the Test Manager built into the IDE is that they run in Debug mode (or whatever your configuration setting is).  That means you can click a break-point, run, and inspect your variables.  For me, that inspection showed that no AppSettings were being retrieved properly.  I soon discovered that tests were running in a whole new place, as previously stated.  The DLLs were being copied, but .config files weren't.  Hmmm...what to do?  To shorten an already long story.... I eventual found this one single beautiful blog post about copying config files in regard to NUnit and TestDriven.net.  Thank you Loren Halvorson!

So here's the deal:

1. In each test project, create an App.config file with your AppSettings you'd normally put in Web.config or your main executable's config file.
2. In your test project's properties pane, select Build Event and add this line to your post-build command line:  copy /Y $(ProjectDir)app.config $(TargetPath).config
3. Run your tests (F5).
4. See the pretty status list and the red and green result indicators. Yay!

My colleauge and I spent quite a bit of time trying to make this config-copying work for other class libraries.  No dice.  The build-event will run on other projects, but the VS Test System will only copy the contents of the bin\Debug directory for the selected test project to the test environment, not any config files from pre-requisite projects. 

The down-side having an App.config for each test project is that AppSettings now have to be maintained in multiple config files.  While hunting for solutions we came across a post by Paul Wilson about including AppSettings from one config file to another.  However, since other config files from other projects don't get copied to the test path, you lose your relative path to them and the inclusion breaks.  Also, only <appSettings/> has a "file" attribute, not <connectionStrings/> as is now en vogue.  You have to put everything in every config file, and you get to use the new ConfigurationManager in all of it's glory.  Be sure to add the System.Configuration.dll reference to your project!