Succedding at Technical Interview

I got this audio on how to succeed Technical Interview.

Father of C and co-developer of Unix died

http://www.wired.com/wiredenterprise/2011/10/dennis-ritchie/

Tribute to Steve Jobs by Bill Gates

Steve Jobs was a visionary peson, here is the link of apple website http://www.apple.com/stevejobs/ and also what Bill Gates said about Steve http://www.facebook.com/BillGates/posts/10150313564426961

Visual Studio and .NET's Unit Test Framework

Microsoft Visual Studio and .NET has its own UnitTest framework which is separate from the NUnit or other Automation Testing Frameworks.

First of all, let's understand What is a Framework? Framework is an Architectural term and it means "Collection of Components".

Code Example of Test Automation using Microsoft Visual Studio 2010

Business Logic which we want to test using Automation
I have a business logic which does some maths calculation and is available via a MathLibrary.dll

The source code of this MathLibrary business logic component is as shown below:

using System;
namespace MathLibrary
{
 public class MathClass
 {
  public int Sum(int n1, int n2)
  {
     if(n1<=0 && n2<=0)
     {
         throw new ArgumentException("No Zero or Negative are allowed");
     }
     else
     {
         return n1 + n2;
     }
  }
}

As it's a dll component so test coverage of this is very critical to make sure that business logic is intact and returning right results.

To do so, instead of relying on a Manual Test Process through a UI which will be very cumbersome and tedious to continuously test the sanity of business logic, we can choose to Automate this test process.

As you might have noticed, we have written the Sum function (in MathLibrary.dll) in a Test Driven, style I.e the parameters passed are also being validated for all the possible test scenarios:
1- If aregument is +ve and non-zero then return the sum of passed arguments. 
2- If argument passed is 0 "zero" then throw an exception
3- if argument passed is -ve then throw an exception

How to approach Test Automation in general

Irrespective of what Unit Test tool and development technology you use Test process depends on two things.

1- Expected - Before we really perform a test our Test case tells us what to expect by this test case to verify success in case of a Sum taking two ints, we expect it to return exact result of adding two numbers.

2- Actual - When you perform the test what your result is.

If Expected meets the Actual then your Test Case is Passed, otherwise your Test Case is Failed

Hence we have to achieve Test Coverage for all the Test Cases in the above mentioned test scenarios.

To do so, we will use Microsoft Visual Studio 2008 or 2010 and then open a New Test Project as shown in the image below:

Now Once you will have this project Loaded, it will have a file UnitTest1.cs in it, this is the file you will be automating all the Test Cases for the MathLibrary.dll (our business logic) we have created.

In order to Automate the Test Cases in Microsoft Visual Studio using Unit Testing Framework, you need to understand few more things:

1- Test Automation Framework - Microsoft has its Unit Testing Framework implemented in a namespace which is Microsoft.VisualStudio.TestTools.UnitTesting

2- [TestMethod] attribute - This is the attribute which needs to be present on each method which will actually represent a TestCase.

3- Assert class - This class is part of Microsoft's Unit Testing framework, and we can use this class to verify if our Actual and Expected are same or not etc.

As mentioned above for each and every Test Case we have to write Automation code.

Note: Before we start coding the Automated TestCases, don't forget to add all the References,
WebReferences etc. which your Test infrastructure will use.

I have covered Four Test Cases for Sum Function in MathLibrary.dll

// Test Case#1: to verify if passed ints are returning Right Result
[TestMethod]
public void TestSumResultAreEqual()
{
   MathLibrary.MathClass objMath = new MathClass();

   Assert.AreEqual(24, objMath.Sum(12, 12));
}

// Test Case#2: to verify if passed ints are Not returning Right Result
[TestMethod]
public void TestSumResultAreNotEqual()
{
    MathLibrary.MathClass objMath = new MathClass();

    Assert.AreNotEqual(25, objMath.Sum(12, 12));
}

// Test Case#3: to verify if passed ints are actually Zero
[TestMethod]
public void TestSumThrowExceptionWhenZero()
{
     MathLibrary.MathClass objMath = new MathClass();

     try
     {
         objMath.Sum(0, 0);
     }    
     catch (ArgumentException)
     {          
         // logging code will go here
     }
}

// Test Case#4: to verify if passed ints are actually Negative
[TestMethod]
public void TestSumThrowExceptionWhenNegative()
{
    MathLibrary.MathClass objMath = new MathClass();

    try
    {
       objMath.Sum(-123, -456);
    }
    catch (ArgumentException)
    {
       // logging code will go here
    }
}

Once you have coded all the Test Cases to Test the functionality, its time to build the code and a TestProjectName.dll will be produced.

There are two ways to Test your automation code now:

1- Using Visual Studio IDE

Build and then Run the project within Visual Studio, you will see all the TestMethods being executed and showing Test Results as shown in the image below:

      
2- Using Visual Studio's command prompt

Open Visual Studio's command prompt and navigate to the folder where the TestProjectName.dll is located and then run this command:

mstest /testcontainer:TestProjectName.dll

           
Summary: This article explained the aproach to Test Automagtion using Microsoft Visual Studio's Unit Testing Framework. Some basic fundamentals about Framework, what is expected out of a test and how to automate a business logic in a .dll form. The same approach can be used to even automate a WebService component etc.

Understanding Access Modifiers/Specifiers in C#

Access modifiers are keywords (private, public, internal, protected and protected internal) which are used to specify the accessibility of a type and its members.

public class AccessModifier

{
    // Available only to the container Class
    private string privateVariable;

    // Available in entire assembly across the classes
    internal string internalVariable;

    // Available in the container class and the derived class
    protected string protectedVariable;

    // Available to the container class, entire assembly and to outside
    public string publicVariable;

    // Available to the derived class and entire assembly as well
    protected internal string protectedInternalVariable;

    private string PrivateFunction()
   {
        return privateVariable;
   }

    internal string InternalFunction()
   {
        return internalVariable;
   }

    protected string ProtectedFunction()
   {
        return protectedVariable;
   }

   public string PublicFunction()
   {
        return publicVariable;
   }

   protected internal string ProtectedInternalFunction()
   {
        return protectedInternalVariable;
   }
}

Now to demonstrate the behaviour how these class members are exposed to another class depending upon their scope defined via modifier/specifier and when we create an object or inherit from the above created class named "AccessModifier"
As mentioned in the above shown code and before each member variable I wrote a comment which describes the access level of each type of member varaible.

So if we derive another class "CallAccessModifier" from the parent class "AcessModifier" then "private" type members will not be visible because its considered as outside the scope of parent class.

But "protected" members are the ones which become available only during the inheritance (when a child is derived from a parent class) as shown via image below.

Showing class members availability through inheritance.

                         
Note:- "this" is a keyword referes to the current instance of the class and used to access members. In the image above this keyword shows all the available members with the classs.

If you notice in the above shown image it clearly shows all the protected members are visible due to virtue of inheritance, along with other members with scope defined as internal, public and protected internal.

Now let's see what happens if we decide to create an object of the class "AccessModifier" shown in the code above. As per the rule private and protected must not be visible via an object:

Showing members available when an object is created of the given class

                     
        
Now as shown in the image just above we are not able to see private and protected members because they both are not exposable via an object.

Besides we are able to see protected internal member, and this is correct because its a mix of both protected and internal and so exposed in here because we are in the same assembly.

Q. What happens if we build a .dll of the "AccessModifier" code and use it in other project.
A. The rules remain the same, once AccessModifier.dll is refered in other project its considered as outside ot the current assembly and so:
 ** private members are not exposed
 ** internal members are not exposed

Windows Azure platform 30 day pass

 

Click on the URL http://www.windowsazurepass.com/?campid=9FE3DB53-E4F0-DF11-B2EA-001F29C6FB82 and use promo code MPR001. No credit card required. With the Windows Azure platform you pay only for what you use, scale up when you need capacity, and pull back when you don't. Plus, get no-cost technical support with Microsoft Platform Ready.