Windows vista and the nostalgic users of command line :D

I needed to copy the windows sdk file (1.2 Gigabytes) from the desktop pc to my laptop, via Ethernet 100 mbps. I begin navigating to the network folder and try to right click the file to select copy. The result is that my laptop get hung….after some while I realized that my antivirus is trying to scan the network file to see if the file is virus free…I immediately terminate the antivirus, and change the option not to scan network files. Then I try to copy the file again, this time I was able to right click and copy the file, I went to destination folder and then do right click, then paste….a message box appears and the file starts to transfer……but my pc is still hung, after 2 minutes the progress bar is about at 15%, so I manually disconnected network cable, the operation was aborted and I decided to open a dos prompt box an type

copy “\\athlon\Download old H\developer\WinFx\OfficialRelease\6*.*”

after 2 minutes the file was on my laptop, but then I decided to move into another folder of the same partition, again I tried to do this through the windows shell, again a progress bar appears telling me something like “calculating time needed to perform the operation”……WHAT???? I was trying to move a file between folder in the same partition…again I stopped the operation, goes again in dos prompt and typed

move 6.0.6000.0.0.WindowsSDK_Vista_rtm.DVD.Rel.img f:\download\WindowsSDK\

The file was moved instantaneously. This poses a question…why these simple operations are really overkill when managed by windows vista shell and are extremely efficient when performed from a dos shell? Whell….I must admit that I’m a nostalgic command shell user J

Alk.

Subversion Versus Team Foundation

This morning I was reading this post, and I must admit that even I with my AbstractView project use Subversion (Google Code) to keep track of the sources of the project. Team Foundation Server and the features exposed through codeplex are really amazing, but when it is time to speak about Source Control I think that Subversion is a product really superior.

I use Subversion not only with Google Code but also with a dedicated server to keep all the source code of the company where I work. Subversion has great performance, it has high integration with the shell (Thanks to Tortoise), has really a lot of options. To be operative with subversion you have to download a little more than 10 mb opposed to 140 mb or more that you needs to download to integrate with codeplex.

In my opinion Subversion is probably the most interesting source control system, and it’s freeware :D

Alk.

Syntax vs Semantic

Yesterday I was reading a post of a friend of mine. In this post my friend complains that these two snippet of code produces very different result.

‘VB code: returns 1.2
Public Function TestDiv() As Double
Dim a As Int32 = 12
Dim b As Int32 = 10
Return a / b
End Function
//C# code: returns 1
public static Double TestDiv() {
Int32 a = 12;
Int32 b = 10;
return a / b;
}

This example opens up a little discussion on witch of the two behavior is the more “correct one” and makes me thinks about programming languages. A programming language is mainly composed by Syntax and Semantics, but it is surprising that a lot of people consider only the Syntax part when they switch from a language to another, ignoring semantics issues. The preceding examples is a perfect situation in which a programmer translate VB code into C# but forget to thing about how the languages interprets the code. But the question is, why languages have different semantics? Why C# returns 1 from the preceding function when a value of 1.2 would be more intuitive? Let’s make some thinkings…

Visual Basic .NET is very different from the older version (VB6 and previous version), but when the redmontonians creates is, they should maintain base semantics when possible. Visual Basic is a language born to be simple, its purpose is to permit to everyone to write a program. The result is that Visual Basic does not requires an intimate knowledge of the art o programming, so when a people write previous snippet, Visual Basic use floating point division even if the programmer ask to divide two integer values. The semantic of Visual Basic is to use the most detailed operation (floating point division) to shield the programmer from the gritty details of the processors.

C# is born from Java and C++, so people programming in these languages are used to know low level details about processors and virtual machines. C# enforces type safety, so when the compiler sees a division from two integers, it use integer division. This is the most logical semantic, if you divide two integer use integer division. Moreover the floating point division is slower in execution and this enforces C# compiler to have this semantic. The good thing is that both languages have Syntax that permits to choose which operator to use.

‘VB code: returns 1
Public Function TestDiv() As Double
Dim a As Int32 = 12
Dim b As Int32 = 10
Return a \ b
End Function
//C# code: returns 1.2
public static Double TestDiv() {
Int32 a = 12;
Int32 b = 10;
return (float) a / b;
}

Visual basic has operator \ , integer division, while C# requires only a cast. The C# approach is cleaner and according to me semantically more intuitive. If you divide two integer use integer division, if I tell the compiler to treat one of the number as float use the floating point division. Visual Basic on the other side introduces a whole new operator, only to express the concept of Integer Division, a solution that is less intuitive respect of C#.

The conclusion is that when moving from a language to another, be sure to keep in mind that is not only a change of Syntax, but be sure to take into account the semantic of new language.

Alk.

Design for testability

Testing a web application can be challenging, there are a lot of tools to accomplish such a difficult task, replay browser capable of recording the input of the user, library as nUnit Asp.NET or WatiN, but in my opinion the best way to do unit testing on a site, is design the site itself to be testable. In the example attached with this article I show a very simple asp.net page to add two integer number together starting from a canonical version to a more testable form. Page Default.aspx shows a standard implementation where all the code to perform the validation and the addition is enclosed in the code behind file. This example is very simple but is significant because it follows a standard path for web.page, validate user input, perform business logic and show result or error messages to the user. What is wrong with this implementation is the difficulty to do a unit test to verify the correctness of both validation code and business logic. (I know that there is no need to test a simple addition, but think as if this example really contains complex business logic).

protected void Button1_Click(object sender, EventArgs e) {
   
if (ValidateInput()) {
      txtResult.Text = (
Int32.Parse(TextBox1.Text) + Int32.Parse(TextBox2.Text)).ToString();
   }
   
else {
      txtResult.Text = 
String.Empty;
   }
}
 
private Boolean ValidateInput() {
   
Int32 num;
   lblError.Text = 
String.Empty;
   
if (!Int32.TryParse(TextBox1.Text, out num)) {
      lblError.Text = 
“Primo addendo errato”;
   }
   
if (!Int32.TryParse(TextBox2.Text, out num)) {
      lblError.Text += 
“ Secondo addendo errato”;
   }
   
return String.IsNullOrEmpty(lblError.Text);
}

Sadly enough a lot of application are written in this way, the first thing to do to make this code testable, is moving away business logic code and verification code in a different assembly, and write some unit test against it. Page3.aspx is a possible result

protected void Button1_Click(object sender, EventArgs e) {
   
if (ValidateInput()) {
      TextBox3.Text = DomainLogic.
Domain2.Add(
         
Int32.Parse(TextBox1.Text),
         
Int32.Parse(TextBox2.Text)).ToString();
   }
   
else {
      TextBox3.Text = 
String.Empty;
   }
}
 
private Boolean ValidateInput() {
 
   lblError.Text = DomainLogic.
Domain2.ValidateInput(
      TextBox1.Text, TextBox2.Text);
   
return String.IsNullOrEmpty(lblError.Text);
}

Now you can see that code behind delegate the business logic and the validation to an external class contained into an external assembly. It is worth to notice that if you put code in app_code directory this code cannot be tested with xUnit frameworks. If you look at the example you can now see that the Domain Logic and validation code can be tested in Nunit project, the test file is called TestPAge3Logic.cs.

But this page is still not fully testable, this because some logic still lurks around code behind file. To achieve full testability really no logic should be included in code behind file, but in page3.aspx we have still embedded the logic of displaying the result to the user. The route to maximum testability lead to Model View Controller pattern, but it is not the subject of this post. If you look at page4.aspx you can see that code behind file really contains no logic.

public partial class Page4 : System.Web.UI.Page, DomainLogic.IPageAddition {
   
protected void Page_Load(object sender, EventArgs e) {
 
   }
 
   #region IPageAddition Members
 
   
public void SetError(string errorString) {
      lblError.Text = errorString;
      lblError.Visible = 
true;
   }
 
   
public void SetResult(string resultValue) {
      txtResult.Text = resultValue;
   }
 
   #endregion
 
   
protected void Button1_Click(object sender, EventArgs e) {
      DomainLogic.
Domain3.PerformAdd(TextBox1.Text, TextBox2.Text, this); 
   }
}

The key is to enclose the operation of the UI in an interface, and make the page implement this interface. In this example the logic of the page can be reduced to two operation: display the result and display the error messages to the user, so the interface contains only two methods: SetError() and SetResult(). The handler of the button now delegate all the work to the Domain3 object, that can be seen as the controller for the MVC pattern. Domain3 has a method called PerformAdd() that contains all the logic of the page, it validates input, calls business logic method, and finally drive the UI to show result or errors. As you can see PerformAdd() method accepts as parameters the raw input of the user as well as an instance of DomainLogic.IPageAddition object. The whole method is really simple

public static void PerformAdd(
   
String addendo1, 
   
String addendo2, 
   
IPageAddition page) {
 
   
Int32 add1, add2;
   
String errorString = String.Empty;
   
if (!Int32.TryParse(addendo1, out add1)) {
      errorString = 
“Primo addendo errato”;
   }
   
if (!Int32.TryParse(addendo2, out add2)) {
      errorString += 
“ Secondo addendo errato”;
   }
   
if (String.IsNullOrEmpty(errorString)) {
      page.SetResult((add1 + add2).ToString());
   }
   
else {
      page.SetResult(
“”);
      page.SetError(errorString); 
   }
}

As you can see this method is really simple and it is Fully Testable. Working this way is the path to Design For Testability, a page designed like this can be easily tested with mock object. Using RhinoMocks we can do a lot of useful tests: first of all we check that the controller does a good addition

[Test]
public void TestGood() {
   
MockRepository rep = new MockRepository();
   DomainLogic.
IPageAddition ipa = rep.CreateMock<DomainLogic.IPageAddition>();
   ipa.SetResult(
“15”);
   rep.ReplayAll();
   DomainLogic.
Domain3.PerformAdd(“12”, “3”, ipa);
   rep.VerifyAll();
}

This test verifies that passing “12” and “3” as user input the controller calls SetResult() method on the UI with the value “15”, but we can do more interesting tests.

[Test]
public void TestWrong2() {
    MockRepository rep = new MockRepository();
    DomainLogic.IPageAddition ipa = rep.CreateMock<DomainLogic.IPageAddition>();
    ipa.SetResult(“”);
    ipa.SetError(“”);
    LastCall.IgnoreArguments();
    rep.ReplayAll();
    DomainLogic.Domain3.PerformAdd(“12”, “32f”, ipa);
    rep.VerifyAll();
}

This test verifies that passing parameters “12” and “32f”, the controller calls SetError(), because the second addend is not an integer number, and also calls SetResult() with an empty string to clear a previous result if present. The key concept here is that the UI is abstracted with an interface, so it can be really simulated by a mock object and we can verify that the controller interacts with the UI correctly.

This little example shows that to really test every aspect of an application, the application itself must be designed to be testable. Moreover, an application designed in this way is really loosely coupled, if we needs to realize a windows version of the UI it is matter of seconds, because all the logic is detatched from the UI.

Alk.

sample11.zip