I Hate Bug Reports

August 26, 2008 Leave a comment

I hate bug reports not because I have an ego and I think I write excellent code which can never have bugs or that I don’t want to fix them but because they often leave crucial information to reproduce the bug and/or what was the expected result and why the results are wrong and I end up in a wild goose chase hunting the testers for answers.

If the tester is not reporting the bug correctly, the developer will most likely reject this bug stating as not reproducible and assign it back the tester. The tester would most probably argue that the bug is there and it can be reproduced and a whole mess ensnares where the developer and tester both end up kicking the ball back and forth at each other. Not only is this time lost in non productivity but it gets pretty frustrating pretty fast.

If you want a bug to be fixed you need to report the bug effectively. So here are just a few pointers to our testers:

  • The bug title should describe the issue completely. Bug title will help developers to quickly analyze the bug nature. It saves time when we don’t need to open the whole bug report to know what the problem is. Keep in mind bug title is used as a reference to search the bug in the bug tracking tool so add in any keywords in the title which you think might help in finding the bug.
  • If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug in the minimalist steps possible. Developers need to be able to get to the problem in the shortest time. Do not assume or skip any reproducing step. Always step through the steps yourself and make sure you don’t leave a step. Make sure your steps are robust enough to reproduce the bug without any ambiguity. Don’t assume that the developers can read your mind – don’t assume that they will do a few extra steps you think are obvious.
  • Never include more than one issue per report. If you have multiple issues, post separate bug reports for each and mark them as related. Reporting multiple bugs in one report will most likely cause your report to be closed when only part of it is implemented.
  • Do not post new bug or feature requests about the same bug or feature. Doing so takes a lot of time for us to merge your reports. The search feature of the bug tracking system is everyone’s friend.
  • Report the problem immediately. If you find any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
  • To create the highest quality bug report which will save developers time and increase the likelihood the bug is fixed, a little extra work goes a long way:
    • Is the bug tied to a single setting or is there a small range of cases? Identify the range.
    • What other user actions cause the error to occur?
    • Does the error occur with different settings or options selected?
  • Attachments are extremely helpful
    • Screenshots with comments really help understand the problem. A picture is worth 1000 words.
    • At the same time a picture should not be there to replace reproduce steps. The bug should still be captured in text even if a screenshot is attached.
  • A bug report should always contain the expected and observed results. Often times the developers don’t think that the bug is a real bug so it helps to explicitly list the expected and observed results. It is the testers duty to explain to the developers what went wrong.
  • Don’t use the bug report as a stepping stone – we have enough politics in the office already.

No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

Oh and one final note; just because the system performs differently that what was expected does not necessarily mean it is a bug. Remember "The best tester is the one who gets the most bugs fixed" – Cem Kaner

Advertisements

Visual Studio 2008 and .NET Framework 3.5 SP1 RTM is here

August 12, 2008 Leave a comment

RTM SP1 for Visual Studio 2008 and .NET Framework 3.5 is out and available for download http://msdn.microsoft.com/en-us/vstudio/products/cc533448.aspx

Visual Studio 2008 SP1 and .NET Framework 3.5 SP1 significantly improve the developer experience during the development process, and at runtime. These improvements address top issues reported by customers. For more information, see Visual Studio 2008 SP1 and .NET Framework 3.5 SP1.

Table-Valued parameter in SQL Server 2005

August 3, 2008 3 comments

In pre-SQL Server 2005 in order to pass in a set of values one had to create a temporary table, populate it with data using INSERT, and then just use it in the procedure or function since they are created for the current session and are available to all processes in that session.

I did a blog on how to pass in Table-Value Parameters in SQL Server 2008 but what if we have a need to pass in multiple rows of data to a T-SQL statement, or a routine such as stored procedure or function in SQL Server 2005?

Turns out the same can be done in SQL Server 2005 without using temporary tables. By using the XML data type you can pass user-defined sets between queries and also between the client and the server.

The following code shows how you can create and use XML parameters.

USE AdventureWorks; GO CREATE PROCEDURE uspEmployeeList(@EmployeeList XML) AS BEGIN SET NOCOUNT ON; SELECT E.* FROM HumanResources.Employee E INNER JOIN @EmployeeList.nodes('/Root/E') AS Tbl(C) ON E.EmployeeID = Tbl.C.value('@EmployeeID', 'INT'); RETURN; END
 

How are XML parameters supported in .NET? ADO.NET allows full support using SqlDbType.Xml type. Adding a XML as a parameter to the stored procedure from C# would have something like:

//string EmployeeXml = "<Root><E EmployeeID=\"1\" /><E EmployeeID=\"3\" /><E EmployeeID=\"5\" /><E EmployeeID=\"7\" /><E EmployeeID=\"11\" /></Root>";
 
// Create the data table
DataTable dt = new DataTable("E");
// Create the table schema
DataColumn dc = dt.Columns.Add("EmployeeID", typeof(string));
// Add a few records to the data table.
for (int i = 1; i <= 10; i++)
{
      // create a new row
      
DataRow
dr = dt.NewRow();
      // populate the fields
      
dr[0] = i.ToString();
      // add the row to the table
      
dt.Rows.Add(dr);
}
... System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand("uspEmployeeList", sqlConn); cmd.Parameters.Add("@EmployeeList", System.Data.SqlDbType.Xml); //cmd.Parameters["@EmployeeList"].Value = EmployeeXml; ...
// Create a temporary MemoryStream to hold the output of the WriteXml method of the DataTable
using (MemoryStream memoryStream = new MemoryStream())
{
dt.WriteXml(memoryStream);
         UTF8Encoding encoding = new UTF8Encoding();
         cmd.Parameters["@EmployeeList"].Value = encoding.GetString(memoryStream.ToArray());
}

Now that’s cool. This is much better than passing in a comma separated list and using a dynamic query in our procedure or function.

Forms Authentication Timeout vs Session Timeout

July 17, 2008 10 comments

We have an old .NET 1.1 web application which I have to support and a recent change in the login process for a select few customers has been causing haywire with every users session. The folks at QA have been giving me a really hard time lately with this bug and I just couldn’t get around as to what was causing this weird behavior.

The problem was that if we set the forms authentication and session timeouts to 10 minutes and after the 10th minute the user clicked on any link the app would redirect the user to the login page but the session was not abandoned i.e. the forms authentication ticket had expired but not the session state timeout. To make matters worse I was unable to reproduce it on DEV or QA instance with my automated test script but was able to reproduce it by manually following the steps.

After a lot of googling I finally realized the solution was right there and I had just overlooked it. The problem was in the way timeouts work for authentication tickets vs session state.

Forms authentication ticket can time out in two ways. The first scenario occurs if you use absolute expiration. With absolute expiration, you set an expiration of 20 minutes, and a user visits the site at 2:00 PM. The user will be redirected to the login page if the user visits the site after 2:20 PM. Even if the user visited some pages in between 2:00 PM and 2:20 PM the user will still be redirected to the login page after 2:20 PM.

Now if you are using sliding expiration for forms authentication and session state the scenario gets a bit complicated. With sliding expiration the session state timeout is updated on every visit but the cookie and the resulting authentication ticket are updated if the user visits the site after the expiration time is half-expired.

For example, you set an expiration of 20 minutes for forms authentication ticket and session state and you set sliding expiration to true. A user visits the site at 2:00 PM, and the user receives a cookie that is set to expire at 2:20 PM. The authentication ticket expiration is only updated if the user visits the site after 2:10 PM. If the user visits the site at 2:08 PM, the authentication ticket is not updated but the session state timeout is updated and the session now expires at 2:28 PM. If the user then waits 12 minutes, visiting the site at 2:21 PM, the authentication ticket will be expired and the user is redirected to the login page, but guess what, the session timeout has not yet expired.

Here is the MSDN link which explains this http://support.microsoft.com/kb/910439

So, how do we synch these two timeouts? Or force the other to timeout if one of them expires? The workaround we came up with was to set the authentication timeout to double the value of session timeout and have the following code in the global.asax.cs.

protected void Application_AcquireRequestState(object sender, SystemEventArgs e) 
{

    if
(Session!= null && Session.IsNewSession)
    {
       
string szCookieHeader= Request.Headers["Cookie"];
       
if((szCookieHeader!= null)&& (szCookieHeader.IndexOf("ASP.NET_SessionId")>= 0))
        {
           
if(User.Indentity.IsAuthenticated)
            {
                FormsAuthentication.SignOut();
                Response.Redirect(Request.RawUrl);
            }
        }
    }
}

Technorati Tags: ,,

Don’t Use SELECT *

July 7, 2008 1 comment

One of the most common performance and scalability problems are queries that return too many columns or too many rows. I’ve seen many developers actually using and abusing SELECT * FROM queries. SELECT * query not only returns unnecessary data, but it also can force clustered index scans for query plans because columns in the SELECT clause are also considered by the optimizer when it identifies indexes for execution plans.

The following two queries show this difference; note the difference in query plans as well as the relative cost to the batch. The query cost relative to the batch is 67% for the SELECT * compared to just 33% for the SELECT column query.

SELECT    SalesOrderID
FROM    Sales.SalesOrderHeader
WHERE    OrderDate< 01/01/1978

SELECT   *
FROM    Sales.SalesOrderHeader
WHERE    OrderDate< 01/01/1978

The first query uses a Clustered Index Scan to resolve the query because it has to retrieve all the data from the clustered index, even though there is an index on the OrderDate column.

The second query uses the OrderDate index to perform an Index Seek operation. Because the query returns only the SalesOrderID column, and because the column is the clustering key, the query is resolved using only that index.

Tags:

Difference between LINQ to SQL and the Entity Framework

June 30, 2008 9 comments

I was browsing through the usual newsgroups I visit and came up with this post about LINQ to SQL vs EDM and thought I should share it here.

LINQ to SQL and the Entity Framework have a lot in common, but each have features targeting different scenarios.

LINQ to SQL has features targeting "Rapid Development" against a Microsoft SQL Server database. Think of LINQ to SQL as allowing you to have a strongly-typed view of your existing database schema. LINQ to SQL supports a direct, 1:1 mapping of your existing database schema to classes; a single table can be mapped to a single inheritance hierarchy (i.e., a table can contain persons, customers, and employees) and foreign keys can be exposed as strongly-typed relationships.  You can build LINQ queries over tables/views/table valued functions and return results as strongly typed objects, and call stored procedures that return strongly typed results through strongly typed methods.  A key design principle of LINQ to SQL is that it "just work" for the common cases; so, for example, if you access a collection of orders through the Orders property of a customer, and that customer’s orders have not previously been retrieved, LINQ to SQL will automatically get them for you.  LINQ to SQL relies on convention, for example default insert, update, and delete logic through generated DML can be overwritten by exposing appropriately named methods (for example, "InsertCustomer", "UpdateCustomer", "DeleteCustomer").  These methods may invoke stored procedures or perform other logic in order to process changes.

The Entity Framework has features targeting "Enterprise Scenarios".  In an enterprise, the database is typically controlled by a DBA, the schema is generally optimized for storage considerations (performance, consistency, partitioning) rather than exposing a good application model, and may change over time as usage data and usage patterns evolve.  With this in mind, the Entity Framework is designed around exposing an application-oriented data model that is loosely coupled, and may differ significantly, from your existing database schema.  For example, you can map a single class (or "entity") to multiple tables/views, or map multiple classes to the same table/view. You can map an inheritance hierarchy to a single table/view (as in LINQ to SQL) or to multiple tables/views (for example, persons, customers, and employees could each be separate tables, where customers and employees contain only the additional columns not present in persons, or repeat the columns from the persons table).  You can group properties into complex (or “composite”) types (for example, a Customer type may have an “Address” property that is an Address type with Street, City, Region, Country and Postal code properties). The Entity Framework lets you optionally represent many:many relationships directly, without representing the join table as an entity in your data model, and has a new feature called "Defining Query" that lets you expose any native query against the store as a "table" that can be mapped just as any other table (except that updates must be performed through stored procedures).  This flexible mapping, including the option to use stored procedures to process changes, is specified declaratively in order to account for the schema of the database evolving over time without having to recompile the application.

The Entity Framework includes LINQ to Entities which exposes many of the same features as LINQ to SQL over your conceptual application data model; you can build queries in LINQ (or in “Entity SQL”, a canonical version of SQL extended to support concepts like strong typing, polymorphism, relationship navigation and complex types), return results as strongly typed CLR objects, execute stored procedures or table valued functions through strongly-typed methods, and process changes by calling a single save method.

However, the Entity Framework is more than LINQ to Entities; it includes a "storage layer" that lets you use the same conceptual application model through low-level ADO.NET Data Provider interfaces using Entity SQL, and efficiently stream results as possibly hierarchical/polymorphic DataReaders, saving the overhead of materializing objects for read-only scenarios where there is no additional business logic. 

The Entity Framework works with Microsoft SQL Server and 3rd party databases through extended ADO.NET Data Providers, providing a common query language against different relational databases through either LINQ to Entities or Entity SQL.

So while there is a lot of overlap, LINQ to SQL is targeted more toward rapidly developing applications against your existing Microsoft SQL Server schema, while the Entity Framework provides object- and storage-layer access to Microsoft SQL Server and 3rd party databases through a loosely coupled, flexible mapping to existing relational schema.

Technorati Tags: ,

Dependency Injection: Factory vs Container – Unity

June 30, 2008 Leave a comment

As application size and complexity increase it becomes more and more difficult to reuse existing components and integrating these components to form an interconnected architecture because of the dependencies of the components. One way to reduce dependencies is by using Dependency Injection, which allows you to inject objects into a class, rather than relying on the class to create the object itself.

Dependency Injection refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The basic value Dependency Injection brings to enterprise systems is decoupling. They promote programming to interfaces and isolate you from the creation process of the collaborators, letting you to concentrate on what you need to deliver while improving testing.

The dependency injection approach offers more flexibility because it becomes easier to create alternative implementations of a given service type, and then to specify which implementation is to be used either pragmatically or via a configuration file, without any change to the objects that use the service. This is especially useful in unit testing, because it is easy to inject a mock implementation of a service into the object being tested.

Dependency injection helps in solving the following

  • You want to decouple your classes from their dependencies so that these dependencies can be replaced or updated with minimal or no changes to your classes source code.
  • You want to be able to write classes that depend on classes whose concrete implementation is not known at compile time.
  • You want to be able to test your classes in isolation, without using the dependencies.
  • You want to decouple your classes from being responsible for locating and managing the lifetime of dependencies.

    The factory pattern described as "To construct and instantiate a set of related objects without specifying their concrete objects." is one common way to implement Dependency Injection. When a component creates an instance of another class, it encapsulates the object creation logic within the component. Any other class that requires an instance of the created class must also duplicate the object creation logic as it may not be reusable outside the component.

    Object most often need to be instantiated in a coordinated fashion, usually because of certain dependencies or other requirements. For example, when creating an instance of XmlValidatingReader in client code, an XmlSchemaCollection object is frequently populated with the relevant schemas for use when validating the XmlValidatingReader object. This is an example of needing to not only create an instance of a class, but also to configure it after creation and before it can be used.

    Another example of a factory pattern is to create a static method whose purpose is to return an instance of a class. For example, the Create method of WebRequest takes in either a string or Uri instance, and returns a new instance of a class derived from WebRequest.

    Factories allow for an application to wire together objects and components without exposing too much information about how the components fit together or what dependencies each component might have. Instead of spreading complex creating code around an application, factories allow for that code to be housed in a central location, thereby facilitating reuse throughout the application.

    Client code then calls creating methods on the factory, with the factory returning complete instances of the requested classes. Encapsulation is preserved, and the client is effectively decoupled from any sort of plumbing required to create or configure the object instance.

    Benefits of Factory Pattern

  • Factories allow for an application to wire together objects and components without exposing too much information about how the components fit together or what dependencies each component might have.
  • Instead of spreading complex creating code around an application, factories allow for that code to be housed in a central location, thereby facilitating reuse throughout the application.
  • Client code calls creating methods on the factory, with the factory returning complete instances of the requested classes. Encapsulation is preserved, and the client is effectively decoupled from any sort of plumbing required to create or configure the object instance.

    Drawbacks of factory pattern

  • While a factory implementation can be quite valuable for a certain application, most of the time, it is not reusable across other applications. Frequently all of the available creation options are hardcoded into the factory implementation, making the factory itself non-extensible. Most of the time the class calling the factories’ creation methods must know which subclass of the factory to create.
  • All dependencies for an object that is created using a factory are known to the factory at compile time. At run time there is no way to insert or alter the manner in which objects are created, or which dependencies are populated. This all must happen at design time, or at least require a recompile. For example, if a factory is creating instances of class Foo and instances of class Foo require an instance of class Bar, then the factory must know how to retrieve an instance of the Bar class. The factory could create a new instance, or even make a call to another factory.
  • Since factories are custom to each individual implementation, there can be a significant level of cross-cutting infrastructure that is held captive inside a particular factory. Take my example of a factory dynamically substituting a proxy object for a real object. That is an example of a piece of infrastructure, namely the wrapping of simple objects for deployment over a distributed wire, that is completely encapsulated inside that particular factory. If another object needs to be altered in a similar manner, the logic to do so is hidden inside a factory, and would have to be repeated for the other object. Once this functionality is desired outside of the original application, the problem now becomes how to reuse such functionality while still maintaining the existing factory concept.
  • Factories rely on well-defined interfaces to achieve polymorphism. In order for a factory implementation to be able to dynamically create different concrete subclass instances, there must be a common base class or shared interface implemented by all classes that the factory will create. Interfaces decouple the construction of the object from the specific implementation of the interface. The dilemma that arises now is how you can accomplish this decoupling without being forced to create an interface for everything.

    A container is a compartment that houses some sort of abstraction within its walls. Typically, responsibility for object management is taken over by whatever container is being used to manage those objects. However, containers can also take over instantiations, configuration, as well as the application of container-specific services to objects.

    Containers provide the ability to wrap vanilla objects with a wealth of other services. This allows the objects to remain ignorant about certain infrastructure and plumbing details, like transactionality and role-based security. Oftentimes, the client code does not need to be aware of the container, so there is no real dependency on the container itself. Containers be configured declaratively, meaning they can be configured via some external means, XML files, property files, or .NET-based attributes.

    Dependency Injection is a worthwhile concept to explore for use within applications that you develop. Not only can it reduce coupling between components, but it also saves you from writing boilerplate factory creation code over and over again. Unity is an example of a framework that provides a ready to use Dependency Injection container. Of course all this also means that there is added complexity to the source code; therefore, it is harder to understand.

    Microsoft Patterns and Practices team had been developing Enterprise Library to enable the use of general patterns and practices for .NET platform, which has great pluggable application blocks such as Logging and Validation application blocks. One of them is the Dependency Injection Application Block; but folks thought it should be named differently from the other application blocks, and came with the fancy name Unity.

    Unity exposes Register methods that support configuring the container with mappings and objects (including singleton instances), and Resolve methods to return instances of built objects that contain any dependent objects. Unity sits on top of another framework called ObjectBuilder which has been a part of enterprise library for quite some time. Unity however is based on v2.0 of the object builder which has been tweaked, refactored and optimized for performance. Unity is available as both a standalone download or part of the enterprise library and can be downloaded from http://www.codeplex.com/unity or http://www.codeplex.com/entlib.

    Unity supports the following forms of dependency injection:

  • Constructor injection – parameters of the objects constructor method are used to inject it with its dependencies.
  • Setter injection – object simply provides a property that can hold a reference to that type of service; and when the object is created a reference to an implementation of that type of service will automatically be injected into that property – by an external mechanism.

    David Hayden has done some great screencasts on Enterprise Library and Unity at http://www.pnpguidance.net/ be sure the check them out for furhter readings on dependency injection using Unity Applicaiton Block.

    Technorati Tags: ,