Bitwise 2008

Bitwise 2008, the annual programming contest held by IIT-K is over. I got 58th rank. Better than previous attempts, but way to go:

2006 - No rank

2007 - 623

2008 - 58

Making sure to handle all exceptions

Usually if a library or a low level function throws an exception, there is a good possibility that it is handled somewhere. However if a GUI function (e.g. clicking a button) has an un-handled exception then the application goes down (crashes). In debug mode the debugger would point out the error but in release mode – the application plainly crashes, on the user’s desktop.

For GUI apps, this can be a concern.

Languages like Java are strict in this case. If a method declares that it can throw an exception, all the callers of the method are enforced to implement an exception handler. Code simply does not compile without handling the exceptions.

In .net you can do two things:

1. read the documentation and find out what kind of exceptions can be thrown. For example if you see the penbox library, every method does list the type of exceptions that can be thrown.

2. blindly add a handler for the “Exception” class – generic type and handles ‘any’ exception.

Approach # 2 is easy to implement. However it is not really a good practice. Exceptions should be really used in case of exception – something you do not expect to happen. Adding a common type of handler has the risk of losing valuable debug information. The exception might have pointed out a logic error (e.g. FormatException in converting strings to numbers). Using the appropriate handler, you can identify such cases during debug and fix the code. Using a generic type handler usually means that you are going to lose this information.

 Approach# 1 is really good. However it can be a pain to read the documentation.

 There is a new tool called “ExceptionHunter” from RedGate. It goes through your .net assemblies (exe or dll) and identifies what all places you have un-handled exceptions. There is a 15-day free evaluation if you want to check out.

C# - Another “finally” trivia

If a function implementation has a try - catch block with a finally clause, then the finally code block is executed in all cases before exiting the function.

For example, in the following case:

int Foo()
{
     try
     {
          //do stuff here
          if(something_happened == true)
               return;
          //do something else
     }
     catch(Exception)
     {
     }
     finally
     {
          MessageBox.Show(”exiting method”)
     }
}

In the above function, even if the function exits at the first ‘if’ condition, the message will still be displayed.

Model based testing

What is the best way to test software?

Delivering quality code and keeping customers happy is the ultimate goal for any software development effort. Common problems people complain about software are that it does not do what they expect it to. Lot of times, particularly in R&D environments the specs are not clear and there are 2-3 iterations before the customers and developers agree that they have a working solution. While ambiguous specs do lead to some kind of re-work, in my personal experience developers do spend time fixing issues reported by the customer. Instead of adding new features, time is spent on fixing bugs in a previous release. If most of the bugs were to be found before the release, there is a good chance of project success as the customers get a stable ‘working’ build.

Software testing plays an important role in ensuring that the application released to customers does what it is supposed to do and without any errors. The definition for testing that I like most is “software testing is running the code in a controlled environment with the intent of finding errors”.  Automated testing has come a long way in ensuring that a software product is tested consistently through its various releases. Through automated testing it is possible to excercise so many scenarios that are impossible to be executed manually within a limtied time and with limited resources.

Helpful as it is, traditional automated testing suffers from the pesticide paradox. Just like how a pesticide can kill only a particular type of pests and how useless it becomes once those bugs have been killed, the throughput from automated testing drops drastically over time. Automated tests are still good for smoke tests and regression testing where you are interested to find if some core functionality is working or if old functionality remained unbroken.

However one of the bigger challenges for product release is to extensively test the software. All the functionalities have to be tested, all the code in the application has to be excercised with various inputs to ensure that the program behavior is verified in all its possible states.

This verification of program behavior in all its possible states is quite difficult with traditional testing techniques.

Here comes Model Based Testing.

In model based testing, a behavior model of the software is constructed that describes all the possible functionalities of the system and the manner in which the software system transitions from one state to another. A typical tool used to represent such behavior models are the finite state machines.

A typical model based testing framework consists of (or is developed as):

1. Create or define a model of the system under test. Examples of models are state transition table or the finite state machines.

2. A separate component then uses the model to generate test cases. From the state transition table or the FSM a directed graph can be built with the different states of the system as nodes and the transitions as the edges. Using graph traversal techniques it is possible to determine a sequence of input actions that leads the software to a particular state. The sequence of input actions form the test case and the final state is the excpected result.

3. As the software evolves, only the model needs to be updated with any new states and transitions. The test suite can then be updated automatically. Another advantage of this methodology is that the expected behavior (test oracle) is also built into the scheme.

An excellent and comprehensive reference to MBT is available at www.model-based-testing.org and www.geocities.com/harry_robinson_testing. This is maintained by Googler Harry Robinson.

In future posts, I will share examples of creating behavior models and also blog about creating a model based testing framework.

Design for a testable rich client application

Using Model View Presenter Pattern for testable applications:

The model-view-presenter pattern can be used to design testable applications. It is quite similar to the MVC pattern except that the view receives messages/ events from the user rather than the controller. The presenter acts as a bridge between the model and the corresponding GUI.

A brief note on value type and reference types

A brief note on value type and reference types

Value type variables simply associate a data in memory to a name. The size of the memory slot is dependent on the type of the variable. For example,

int a = 10;

There is a slot of 4 bytes (for integer type) on the stack and the name for the slot is ‘a’.

Reference type variables always point to a location on the heap. The size of a reference type variable is always 4 bytes (32 bit systems, 8 bytes in 64 bit systems). This 4 byte reference points to the actual data on the heap.

Rules:
1. reference variables created on stack get destroyed when the stack unwinds (e.g. control exits out of the function). Note here that the actual data this variable was referring to will stay in memory as long other variables are referring it.

So irrespective of value type or reference type, all local variables are stored on stack.

2. Function parameters are also local to the function and stored on stack. However if the parameter has an ‘ref’ modifier then this argument shares the slot with the variable in the calling function.

3. Instances of a value type are stored in the same context as the variable that declares the value type. For example if a struct (value type) is defined as a data member in a class (reference type) then in all instance of the class, this struct instances will be created on heap.

4. Static variables and strings are always stored on the heap. Static variables are NOT stored on the garbage collected heap but on a different one called the high frequency heap.

5. If you declare two strings in a class like
string s1 = “ABC”;
string s2 = “ABC”;

note that both have same value. In such cases only one “ABC” is created on the heap and s1 and s2 will be referring to this memory location. If either s1 or s2 gets changed then a new string is created.

Further reading:
1. What is “ArrayList” and what are its uses
2. What is boxing in .net and why is this important
3. what are generics in .net 2.0 and what problem do they solve?

Google desktop gadget idea

At work we decided to start using Kanban cards as a part of adopting agile development process. We started off using infopath to create tasks and then asign timelines for each task.

For sometime, wanted to create a desktop gadget using the google SDK. Sounds like it will be good idea to create a gadget application that allows one to create tasks, manage time lines and progress and then also share the task list with colleagues. Finally it will be also possible for  the managers to create reports from the tasks. The only drawback could be that communication between similar gadgets across different computers is through google talk so not sure how it would fit in the office (e.g. would the network security team allow it?).

Even for a single user, this looks like a good idea. The gadget will have the following features:

1. Create project list

2. For each project, add list of tasks to be completed in a week

3. Add descriptive notes for each task if required

4. At any time later pull out any task and assign the start time/ start date and end time/ end date. End date or someother flag signifies that task is closed.

5. Be able to create time summary (and other reports) project wise. For example at the end of the week find out how much time was spent on each project.

Seshagiri

‘finally’ pitfalls

The ‘finally’ clause is very helpful to do clean up operations when working with costly resources, database connections etc. Even when an exception occurs, the finally clause is guarenteed to be executed thus ensuring that there are no resource leaks.

The pitfall is that its quite easy to end up writing some functionality code in the finally clause thinking that it would be executed after certain tasks. For example you might put your report writing code in a finally clause. So in case an exception occurs, the functionality code is also executed resulting in even more bugs!!

Scripting in .net applications

One advantage of scripting is that it helps in application customization. Giving end-users the ability to add extra functionality without having to modify our source code is something great.

Lot of commercially succesful software owe part of their success to this programmability. Eg. VBA in word, excel, VSS and so on.

Scripting engines also can come in handy when you want to implement plugin capability to your application.

Actually there are two different areas of scripting - conventional “shell” scripting and “application” scripting. Any exe supporting command line arguments could be automated using the shell scripting. The latest windows shell “Monad” is something lot of people are excited about.

Coming to application scripting e.g. VBA enables programmers add extensibilty to their applications. So end users could write scripts and using some standard interfaces the host applications will be able to execute them.

Because C#.net is increasingly becoming choice programming language for desktop apps and web apps alike, scripting support for .net apps is also picking up. VSTA (visual studio tools for applications) is a SDK provided by Microsoft which users can include in their applications. The VSTA comes with a VB like IDE which can be invoked from customer applications using the famous ALT-F11 keystroke sequence. This is slated to be released in Oct 2006.

Seshagiri

How would you test a library or API

API or library cannot run by themselves so you need a host application to test the library. But in such case the test application itself might have bugs so you might not be reliably testing the library. So how would you test a library?

I think the following three will help:

1. Unit tests

- test developer writes code which invokes each of the public methods in the library and compares the result of the API to a preset expected result.

2. Stack trace

- If the library supports call tracing one could create a “goldenfile” listing the call stack observed when calling a particular public method of the library. In subsequent tests, any differences with this golden file will be treated as failures and shall be investigated.

3. Test hooks

- Test hooks help a lot when automating the tests. For example, in GUI test automation, if you add a special method which allows passing a “click” message to a button, the test developer can use this method in his automation code to simulate a click event.

 In my next article I will write about a design I am using to make my rich client applications testable.

Seshagiri