SpotGnome.com - Friday, January 04, 2008

Friday, January 04, 2008

Dirk Jesse’s extensive (X)HTML/CSS Framework offers the whole bunch of default-templates for a number of simple or more complex web-projects. YAML is based on web standards and supports every modern web browser. All Internet Explorer’s major rendering bugs are countered. YAML fully supports all IE versions from 5.x/Win to 7.0.

Apart from a number of standard-conform layouts the framework also offers a debugging stylesheet, print stylesheet as well as various robust tools for web-development in YAML. All CSS components of the framework as well as the various layout methods are thoroughly documented in both English and German, supplemented by numerous examples.

YAML Builder

You can also use a YAML Builder to develop your layout visually - in your web-browser. You can choose a Doctype, basic layout elements (#header, #footer, …), the number of content columns as well as preferred column order and set the layout and column widths. You can also drag & drop and nest both sub-templates and dummy content, display and output the complete code (XTHML markup and CSS) and switch between draft mode and preview of the finished layout.

Blueprint

The Blueprint CSS framework, created by Norwegian tech student Olav Frihagen Bjørkøy, is a very promising foundation for developing typographic grids using CSS. The framework offers an easily customizable grid, sensible typography, a typographic baseline and a stylesheet for printing. It also uses relative font-sizes, provides a CSS reset and is supposed to be cleaned of code bloats. The latter isn’t always true.

Besides, you can also use the Blueprint Grid CSS Generator to generate more flexible versions of Blueprint’s templates. Whether you prefer 8, 10,16 or 24 columns in your design, this generator now enables you that flexibility with Blueprint CSS Framework - a new “to-become-standard” in grid-based design approach.

Yahoo! UI Library CSS Foundation

Yahoo! UI Library presents a set of CSS frameworks: the core YUI CSS foundation includes the Reset CSS, Base CSS, Fonts CSS, and Grids CSS packages.

While Reset CSS removes and neutralizes the inconsistent default styling of HTML elements, Base CSS applies a consistent style foundation for common HTML elements across A-grade browsers.

Fonts CSS offers cross-browser typographical normalization and control; the framework provides consistent font sizing and line-height, supports user-driven font-size adjustment in the browser, including cross-browser consistency for adjusted sizes and works in both Quirks Mode and Standards Mode.

Grids CSS delivers four preset page widths, six preset templates, and the ability to stack and nest subdivided regions of two, three, or four columns. The 4kb file provides over 1000 page layout combinations. The framework supports easy customization of the width for fixed-width layouts; it also supports fluid-width (100%) layouts as well as preset fixed-width layouts at 750px, 950px, and 974px, and the ability to easily customize to any number. YUI also offers The YUI Grids Builder — a simple interface for Grids customization.

You should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and div-containers in CSS. Yahoo! UI Library also provides a detailed documentation with numerous examples, tutorials, cheat sheets, templates and tools.

Friday, January 04, 2008 11:49:10 AM (Jerusalem Standard Time, UTC+02:00)

Comments [0] - Trackback
CSS | Design | Site Reviews

Wednesday, January 02, 2008

Automated GUI testing - Is it worth it?

In 2007 I've worked with NUnitForms. It contains all major controls testers and you can easily create your own ones for e.g. a Data Grid or a 3rd party control. I had to create one for Janus GridEx and it wasn't really that hard.

A little reflection went a long way :) Lately, the whole project was at a standstill for some time but now it seems it's revitalizing nicely with new people on board. So if you haven't yet go take look. This is just one open source GUI testing platform and I'm sure there are others... I haven't checked them out though.

Now to the big question: Is it worth it? It depends...

I'm not a hardcore TDD practitioner but I like having repeatable unit tests. But having automated GUI unit tests is in my opinion a waste of time.

Why? It simply isn't worth spending time writing them. You should have enough code coverage with non GUI tests to find any bugs long before hitting the GUI. You might want to be tempted to unit test control positions or visibility or some other property... don't bother.

You'll spend your time better if you write more non GUI unit tests and check your GUI by hand (eye).

So what are they useful for? Well... I've used them for acceptance and integration testing with great success.

Integration Tests...

... test how different parts of your application work together. These kinds of GUI tests proved to be VERY useful and they are worth investing time in. They have a great ROI (return on investment) once they're written. For example we had a large workflow based application that was completely async in nature. It had a windows forms client that could be deployed on multiple computers, all those clients connected to a single server that hosted a few webservices for data modifications, retrieval and some other stuff.

The whole app was also connected to Sharepoint server, Exchange Server, SQL Server, used InfoPath and a 3rd party software to export data from and into it. With one single GUI integration test we could easily see if everything worked together as it should. We mocked the InfoPath and 3rd party software but everything else ran great.

The point of using GUI tests here is to see how and if your whole application works with all parts integrated together from GUI interaction to Exchange connectivity. Even the best non GUI integration tests simply don't do that.

Acceptance Tests...

... test if your software is up to some specs usually defined by the business process. They're in essence a black box test. You don't care what goes on inside the software you just want to see if the output is correct for a certain input. In workflow based processes this can be very useful since you know what the input and output parameters are for your workflow.

For example you start the workflow in your app via NUnitForms, pressing "move in workflow" buttons until the workflow end and then check if the output parameters have the correct values. You can check for various different GUI parameters in this test along the way but as I said above don't go overboard. I usually just check for visibility of certain panels or grids... simple things like that.

When I first started with GUI testing I thought it was a really big waste of time. And to tell you the truth if you don't draw the line somewhere it is. I even had a moment when I thought it was a good idea to test everything only with GUI tests. That was so far over line I couldn't even see it anymore. Luckily that moment passed pretty fast. Don't make the same mistake. If used wisely automated GUI tests are a big benefit.

Wednesday, January 02, 2008 11:39:05 AM (Jerusalem Standard Time, UTC+02:00)

Comments [0] - Trackback
Programming | Visual Studio

Thursday, December 27, 2007

C# 3.0 - Partial Methods

Partial methods are a new feature available in C# 3.0 that don't seem to get enough credit. I think there was a lot of confusion early on about what partial methods were and how they were used.

Partial methods are intended to solve a major problem that is not only caused by code-generation tools and also affects those same tools. For instance, you are writing a code-generation tool but want to provide a way for the developers that are using your generated classes to hook in to specific areas of the code. As such, you don't want them editing your generated code since those customizations will be lost the next time the tool runs. On the flip side of this scenario is the developer who needs to write the code that hooks into those specific areas and doesn't want that code being lost the next time the tool runs.

Delegates are one solution to this type of problem. In the generated code, you declare a delegate method that you then call at the appropriate areas. If no one has implemented a concrete version of the delegate, the call will not do anything. However, if someone has implemented am instance of that delegate then the call will run the code in that instance. This sounds like a pretty good solution, and, until partial methods it really was the only solution. The drawback is that the code for the delegate is always compiled in to the runtime of your application and add to the runtime overhead of application (granted, that overhead is minimal but it's still there).

Partial classes helped with this problem by allowing the code-generation tools to isolate the generated code in a partial class. This allowed the developer to add their own methods to the class without fear that they would be overwritten the next time the tool ran. However, it only helped partially. In order to accomplish our scenario, you still needed to provide a delegate to allow the developer to hook into your process.

If we take this a step further and look at partial methods, you will start to see how they work and what the benefit is of using them. The following rules govern how partials methods can be declared and used:

Must be declared inside a partial class.
Must be declared as a void return type.
Must be declared with the partial.
Cannot be marked as extern.
Can be marked static or unsafe.
Can be generic.
Can have ref but not out parameters.
Cannot be referenced as a delegate until they are implemented
Cannot have access modifiers such as public, private or internal.
Cannot be declared as virtual.

Partial methods are implicitly marked as private. This means they cannot be called from outside the partial class.

Now that we have the rules out of the way, let's take a look at an example. This is a completely contrived example, as you typically wouldn't declare both portions of the partial class yourself.

   1: // This is the class that would normally have been autogenerated.   2: public partial class CustomTypedCollection   3: {   4:     partial void BeforeAddingElement(CustomElement element);   5:     6:     public void AddElement(CustomElement element)   7:     {   8:         BeforeAddingElement();   9:     }  10: }  11:    12: public partial class CustomTypedCollection  13: {  14:     partial void BeforeAddingElement(CustomElement element)  15:     {  16:         Console.WriteLine("Element " + element + " is being added.");  17:     }  18: }  19:    20: class Program  21: {  22:     static void Main(string[] args)  23:     {  24:         CustomTypedCollection c = new CustomTypedCollection();  25:         c.AddElemeent(new CustomElement());  26:     }  27: }

In this example, the code-generation tool declares a partial method BeforeAddingElement. It is declared as just a function prototype with no implementation. Effectively, this tells the developer that if they want to hook in to the AddElement process, they can do so by declaring an implementation of the BeforeAddingElement method. If an implementation is declared, the implementation and the call inside AddElement will be compiled in to the runtime code. However, if no implementation is declared the call will be optimized by the compiler and it will be entirely eliminated in the runtime code.

This mechanism provides a lot of the same flexibility as delegates without the runtime overhead. It also allows the developer to work with a much smaller implementation of their portion of the partial class that contains only the few partial methods that have been implemented.

Thursday, December 27, 2007 7:53:47 PM (Jerusalem Standard Time, UTC+02:00)

Comments [0] - Trackback
.Net | Programming | Visual Studio

Navigation

Home