The testing pyramid

For those who aren’t familiar with the testing pyramid (or who don’t remember), the principle is as follows:

Mike Cohn

The bottom tier has to be automated the most: it gives the best ROI as unit tests can be easily written by developers and gives them an immediate feedback. The more automated unit tests, the stronger will be the foundation.

The middle tier is more difficult to automate than the foundation and tests at this level will be focused on business-facing tests. These functional tests will give an answer to the question “are we building the right thing”. It will ensure functionalities match the requirements.

The top tier will the least automated tests because this level is usually composed of UI tests that are expensive to write or maintain and that often require human control (over visual aspects for instance).

What the pyramid misses

I think the pyramid is very useful and test teams can gain efficiency if they follow its principle. However, something is missing…

Tests in this multi-layer system are being executed by different people, and all these tests are of different nature. This introduces one more difficulty: there is no aggregated vision of all these different tests. For instance, it is hard to get a  complete picture of acceptance and GUI tests.

As a result, teams can leave “testing holes” within their application: software areas that are not covered by any tests and it is more likely that bugs will slip through the net of your testing in these areas!

Unknown risk coverage

However it is almost impossible to reach 100% test coverage of the software. So how to assess risks related to these “testing holes” in order to decide which tests should be added?

We suggest 2 ways of doing this assessment in order to have the right focus for additional tests.

1. Focus on regression risk

The point is to compare the current version of the software you have to test with the previous one. This comparison will allow you to identify changes where regression risks are higher.

Mixing this information with test coverage clearly identifies regression risks that have not been covered by any test.

As a picture is worth a thousand words, let me show you that new principle:

Known risk coverage

2. Add business perspectives

Even with a focus on untested changes this could still be too large when you haven’t yet got a high proportion of automated test. So in addition, we recommend adding a business perspective: drill-down to untested changes by features or  software functional areas. So you can focus your additional testing activities where bugs should be avoided in order of priority.

Functional view

Ok, but what do we do when we don’t have a high number of automated tests?

Let’s jump to the top of the pyramid, this is where you will need to have more manual tests if your coverage by automated tests is weak. In such a situation you won’t have enough time to execute all the manual tests
every time. You will have to select relevant tests and execute them depending on their priorities and on what has not been tested at lower levels.

Combining changes, coverage and business perspectives, not only will you optimize the time you spend on testing by balancing automated and manual tests, but you will also focus on relevant tests (and thus avoid losing time with useless  tests) and ensure you covered the risks in the application.

Adding test footprints

During testing, Kalistick’s agent can record all the execution paths through your application. This is not about record/replay but linking test cases and code so that when changes are made in a release, relevant test  cases to cover the corresponding regressions risks can be identified.

As you can imagine, the technology is self-learning. The more tests you execute, the better the software is going to know yours and be able to help you to build more efficient regression test strategy.

The goal of this technology is double:

1. Optimizing test efficiency by selecting relevant tests for a test campaign and avoid losing time with useless tests which aren’t testing changed modules
2. Ensuring that all risks are covered, even indirect risks dues to indirect impacts of certain changes (mainly regressions thus)

Conclusion

On your way to reach the right balance of automated and manual tests at each level of the pyramid this technology will help you improve your software testing efficiency.

SoapUI : using this integration with SoapUI by SmartBear, you get your real tests coverage within the application and you detect untested code changes that leave the door open to undetected regression.

Selenium : largely used by our Agile customers they have asked us to to integrate our technology to Selenium. Now you are able register all your test coverage and  to detect holes in your tests through the code and changes coverage analysis.

QTP : in the field of automation tools, we had to integrate Kalistick to HP QTP. With Kalistick, you record all your automated tests coverage and you identify untested areas that could need additional testing activities. It helps you find the best balance between automation and manual testing.

HP ALM (QC 11): Kalistick was already integrated with Quality Center 10. With QC11 ALM, the integration is going further by allowing you to optimize your regression test strategy and to follow your functional test coverage.

XStudio: XQual delivers XStudio, a free test management application that handles the complete life-cycle of your QA/testing projects. With Kalistick plugin, it’s easy to re-run only the tests that are necessary after code change.

All these integration are built with our public API that open our technology to any Test Management Solution or Automated Test tools.

In order to give an always higher quality level, we continuously work on new integrations with the essential test tools. Our platform already integrates with over than 35 tools dedicated to software testing and development.

If you think about a particular tool we should integrate with, please tell us in the comments!

An idyllic vision of test automation

Automated testing is undoubtedly an ideal solution for having the capacity of replaying test for each version of an application, and thus avoiding regressions. First steps with automation tools are generally awesome, but…

A reality not so bright

It appears that this “ideal” is not always fulfilled. Depending on projects and contexts:

• Application’s functionalities and UI are not stable enough. They change with each version and thus require manual intervention on automation scripts. Maintenance costs of test scripts become too important.
• Data are not stable on a long term basis and it is hard to control results. Analyzing every result requires as much time as executing the test.
• Visibility on real test coverage is poor. We’ve got automated tests, but knowing if they are relevant regarding to regression risks related to the evolutions is very different. Basically, you play the tests, but it doesn’t avoid regressions.

So, here is the reality as seen with our clients: there sometimes are automated test. When there are, it’s no more than 20% to 40% of tests overall!

For manual tests remaining, an efficient test strategy is essential. Available resources and time are impeding testers from executing all the tests.

How to define a non-regression strategy

Identification of regression risks

It is essential to have a clear vision of risks in order to define an efficient test strategy. Otherwise, selecting relevant tests is extremely hard.

However, this clear vision is not easy to obtain.

As explained in a previous article about misunderstanding between developers and testers, developers are failing to provide test teams trustable information. Thus, no way to surely identify impacted functionalities nor risks.

Our technology is taking a picture of each version of the application. It then compares each picture to precisely identify changes and their functional impacts. Thanks to that, we you can get a clear picture of risks to cover for each version, whether major of minor.

Identifying the right test cases

Beyond risks identification, it’s necessary to select test cases that effectively cover those risks. And selecting them becomes more complex with an increasing number of tests.

Our technology is unique. For each test execution, its real footprint on the application is recorded. We accurately identify what’s tested in the application (executed code) by one test. We called it “Test Learning System”, and it’s automated.

By correlating this footprint with version analysis, our platform can identify which scenarios are relevant for covering the regression risks.

Prioritizing tests regarding business issues

Identifying tests is a good point, but it can also be necessary to prioritize them.

When time runs out and you can’t play all of the tests, better to be sure you started with the good ones. This is Risk Based Testing.

By identifying each functional module of the software, Kalistick’s platform allows to associate a business criticality level. It is then crossed with footprints and modifications in order to select and prioritize test scenarios.

An integrated wizard also allows polishing the strategy until the number of scenarios can be played in the allocated time with the available testers.

Trustworthy test coverage indicators

During the test stage, Kalistick’s platform brings a detailed vision of the risk coverage progress by identifying tested and untested elements. Thus, it becomes possible to identify the eventual falls through the net and to stitch them up before going live to production.

This vision of coverage highlights complementarity between automated and manual tests. After an automated test campaign, it allows to identify remaining parts to be tested as well as the most relevant manual tests.

In conclusion, it becomes possible with Kalistick to define more efficient regression test strategies that are balancing time, costs and risk coverage, and to adapt them to every business context, project or version.

The basic use of test coverage…

Most of the time, for functional test teams, test coverage is a control matrix that links risks, requirements and test scenarios.

As soon as scenarios match the requirements, the known risks and that they are successfully run, the coverage is validated and theoretically covers the risks…

Or strategic use

However, it is possible to approach test coverage from a new way. This way will give richer information that will be really useful for test improvement. It will allow testers to improve test efficiency.

Decrypting test coverage

What is that?

Test coverage is seeing the real coverage of tests in the application. Shortly, it’s analyzing what has been executed in the code by tests. We call it the “footprint” of tests in the software.

Global coverage

Globally on an application, it becomes possible to see accurately:

• What has been tested
• What hasn’t been tested

It will allow testers to make sure every single part of code is covered by a test scenario at least. But as testing all of the application is rarely possible regarding the short period of time allocated, we need more data…

Enrich the information

In order to exploit even better the test coverage knowledge, it is ideal to double check that tests are covering the changes that has been made in the software while validation stage. This will permit testers to better anticipate regression risks.

For doing this, unexpected changes must be identified first, and then the code has to be checked to reveal if weather or not it is covered by a scenario.

If some parts of the added code are seen as not covered, test teams can react very quickly and focus on these specific highly risked areas.

Of course, the closer is the deadline; the most important is the information. During the last test stages, it is absolutely impossible to re test all over again. It becomes a must to only select a few test cases and to make sure nothing has been missed.

And it’s the same scenario for minor versions or patches: allocated time and test load are making it impossible to re test all over. Identifying test scenarios impacted by changes allows focusing on relevant tests. This increases the team’s reactivity.

Case by case even more efficient

Individually looking the footprints gives an even finest details level.

With traditional test tools, test coverage is seen global: test execution paths in the application are not considered. Even test are not differentiated.

By capturing every scenario footprint individually, Kalistick brings a high value data to test teams.

When executing a test scenario, each and every executed action on the software is recorded. Thus, when a new version is received during a validation stage, if certain tests have already been executed, the system will detect which results can be compromised by the new version (when the footprint has changed).

If a choice has to be made between scenarios, or if you work with Risk Based Testing, Kalistick brings an ideal additional information. Based on each scenario’s footprint on code and on the application’s functional risks, the system shows which scenarios are to be run for each functional subset.

The “Test Learning System”

It is the name of the software that will help you improve your tests!

Here is how it works:

• When a test is played, it is recorded
• Every action executed on the application during the test is linked to the part(s) of used code
• The link between the test and the code is defined
• A new footprint is created

Thanks’ to its integration to HP Quality Center; the operation is very simple and automated. For each test execution, the process is automatically run and a new footprint is created. And in case the test has already been executed, the new footprint will be compared to the previous one; if changes happened, they are immediately identified.

Secured Go-live decision

Thanks to the Test Learning System, the Go decision is safe. Indeed, the real risks coverage is 100% known. If all tests are validated, then no unknown risk can impede the production.

Developers and testers don’t speak the same language. This strongly reduces test teams efficiency!

Developers talk about files, class or code; testers talk about test case, business needs and functional scenarios. In other words, communication isn’t working.

The consequence of this misunderstanding, just like we talked about in the post concerning test efficiency improvement, is the blindness of test teams.

The content of received versions is a mystery, just like changes and impacts. No way to direct the test strategy toward risks. Or with extremely low confidence.

This communication problem is perfectly pictured by the trials of developers to make changes clearer: testers don’t get a thing! Why?

Release notes are aiming to point out the modifications. But in fact, the content is too technical for testers, sometimes too general or even declarative. The usefulness of these notes is then more than questionable…

The question is: what are the impacts of these misunderstandings?

• Hardly assessed regression risks
• Difficulty to select the appropriate test scenarios
• Impossibility to make sure the regression risks are well covered

In short, misunderstanding between developers and testers is a major source of test process inefficiency. And this generates regressions that only surface when in production.

What’s up, doc?

Information with every delivery is a good start…

During validation stage of a version, regression risk is increased with every new delivery (estimated to 8% of bugs found in production).

Executing 100% of test cases at each delivery rapidly appears as unrealizable. The shortest is the given time; the narrowest is the scenarios selection, and the more are missed regressions.

In order to avoid this infernal cycle, testers must get a clear vision of changes and their impacts for every delivery.

Trustable information is much better !

For test teams to be able to rely on this information, they must be trustable. The discussion we have with our clients shows that when the information is given on a written support by development teams, trust is lowered.

It seems a specific tool is needed to compare the received version to the previous one on the overall of its features (code, setup, third party libraries, etc). This would allow testers to reach the high trust level they are looking for.

I have a dream… to get relevant information!

Having information is essential, but this information must be usable by test teams!

Dealt functional requirements, dealt User Stories… These data can’t be missing for functional validation. But they are hardly usable by the test manager for defining the regression test strategy.

Moreover, it’s rarely comprehensive! New changes would have been done. With no record on functional requirements or anomalies most of the time.

Exploratory tests will try to catch related risks, but often with a very low efficiency.

For improving this matter, our clients helped us define 2 levels of useful information:

• Business view, for knowing changes and their impacts. Returning information through impacted sub-sets of the software will allow targeting test efforts toward highest regression risks.
• Impact on scenarios, to identify scenarios to replay. Identifying the footprint (executed code during a test case) of every test on the software’s code will point out test cases impacted by a change.

What if you could “Test right”?

If this difficulty to communicate between dev and test teams could fade away, what could become of tests?

This is what we call “Right testing” (see our concept “Smarter Testing Strategies”). An open door to a new strategy which tend to solve this equation:

To more efficient tests and beyond !

This series on test efficiency improvement will go on in two coming articles:

• How to exploit test coverage to master and anticipate risks?
• How to define a more efficient non-regression test strategy?

We will also talk in a soon article about reverse communication issue: when developers don’t receive the right level of information from testers.

Thus, how to analyze, diagnose and correct an anomaly? A classic problem that feed bug trackers of “un reproduced” bugs. It is also the reason why the number of deliveries needed to correct an issue is increasing.

Based on these observations, one thing stands out: improving test efficiency is a major challenge for almost all of them.

One more thing they have in common: trying to achieve better efficiency, they are always slowed down by the same problems, again and again…

We decided to share with you these problems that are poisoning a lot of test teams. Then, we will introduce the solutions that our clients have implemented for their testing.

Why test teams need more efficiency?

Top 3 major and recurring issues

According to our clients, 95% of them encounter 3 major issues while testing:

• Increasing complexity of software: no more monolithic and autonomous applications, welcome to endless inter-integrations (through web services for instance). These integrations are increasing risks with every evolution and make testing more complex. Better testing become unavoidable: despite increasing risks, time and people allocated to software testing remain the same.
• Acceleration of the pace of versions: application’s evolutions are a must for business teams. New versions may contain fewer evolutions, but tests aren’t much easier. Of course there is no way to re-test all over every time. Better test strategies are then essential.
• Endless modification on every level: new functionalities are added to applications; new applications are added to IS… In summary: a ton of new risks are added. Quality requirements might not change, but means are never increased either!

Two weeks ago, a client was telling us about his rather unpleasant experience:

Identified inefficiency sources

Beyond the increasing need of efficiency, our clients share three important sources of efficiency loss during testing:

• A bad visibility on delivered version content
• Low quality modifications
• A high number of iterations to validate a new version

3 cannonballs testers are chained to

No good test without good visibility

In most cases, test teams complain about the lack of visibility on developments made by project teams. The impacts can’t be clearly identified and it is not possible to turn the test strategy toward these risks (or with a very limited confidence).

This bad visibility is due to multiple situations:

• Test teams and dev teams work in a “silo” mode. This mainly happens when development is externalized to a contractor, but not only.
• Developers and testers work together in the same open space; but they don’t speak the same language! When developers say file, class or code, testers want to hear about test case, business need and functional scenario.

The first attempts to improve it are the release notes. Here again, the content is too technical to be used by testers, sometimes too general (just a list of requirements associated to the delivery) or even just declarative and judged not reliable enough.

Consequently, functional validation manager can’t get a clear picture of modifications and their impacts to select the appropriate scenarios to cover risks.

To better understand the consequence of the lack of visibility, here is a customer case:

4 days before validation ending –a last version of the software just arrived. It contains 10 fixes that have to be validated and we have to make sure no regression have been introduced.

Not only this circumstance generates bugs that will be found when the software is on production, but moreover, finding the bug’s source will be particularly difficult.

Low development quality: an obstacle for testers

Development low quality has a strong impact on business test teams. The link might not be obvious, but we often encounter this context:

• Frequent regressions on every delivery as the code is hardly maintainable: any change is very hazardous. A real case with got with many clients: copy / paste in the code. This means more iteration to correct the same bug everywhere!
• Technical anomaly found by business testers that are very hard to reproduce, to document and thus to correct. These anomalies are generally classified as “not reproduced” but surface in production context.
• A development team that prefer delivering on time even if they didn’t pass all the necessary technical tests (sometimes with little unfinished development). As a result, many changes in the next delivery (back to “Lack of visibility point”!) and test results very questionable. A very common regression source!

The lack of quality is not noticeable only in production. With “black box” tests, linking certain issues and their origin is very difficult. Yet, if this “black box” could be opened, the link is obvious!

Number of deliveries: a key performance indicator ?

To every new delivery in a validation stage, there is an associated risk that generally is badly handled. Any change can question the result of an already passed test while the risk won’t even be perceived!

Many studies, like the ones of IBM and Caper Jones, are pointing that the impact of such circumstance is huge:

In order to avoid this situation, some companies choose to delay the non-regression test campaigns. But it is impossible to delay it forever, and issues always catch them up.

Thus, tests perception is degraded: they look useless whereas test team is doing its best to avoid the problems. The team tries to adapt test plans to each delivery and increase the test efforts when approaching the deadline.

Improving test quality: a dead end ?

There are solutions out on the market that allow test teams to focus and anticipate these problems that undercut their efficiency. We will analyze the solutions our clients implemented in an article series to come. We will talk about how to:

• Get a good visibility on received releases
• Exploit test coverage in order to manage and anticipate risks
• Define a non-regression test strategy really efficient

Meanwhile, if your company is facing problems we didn’t talk about; please share with us in the comments!

We needed a new way to introduce Kalistick, more friendly and dynamic. The video seemed to be the perfect mean to quickly present our product (1 min 10) in a simple way. But what kind of video ?

After a bit of hesitation, we stopped our choice on an After Effect template. A few days of customization to make it match our needs, and the first feedbacks: mostly positive.

Enough talks, here is the video (720p available for full screen):

We tried to convey our main point:

How to anticipate risks and to make sure the application is well covered by tests during testing process, so to lower regressions.

We answered that by the 4 strenght of our platform:

• See changes and impacts
• Focus on the right strategy
• Control test coverage
• Secure Go-live decision

So what is your opinion ? Do you think this video is clear and dynamic enough ?

In the previous posts, I talked about the C# language: its differences with Java and its “unique” features. In this one, I am going to introduce the ecosystem. A language can be the best one in the world if its platform and tools are not as good, it will be useless. That is why I will focus, in this post, on the .NET platform in a whole: framework, libraries and tools. The time when knowing the language in and out only was enough is long time gone now.

• Part 1: Differences in similarities
• Part 2: A brand new world
• Part 3: The ecosystem

No good building without a good foundation.

Apart from the language itself, the standard framework is the part with which you interact the most. It is crucial that this framework provides facilities for basic day-to-day operations needed when writing an application, like reading/writing a file, parsing a text or sending a request over the network.

Long story short, the .Net Framework base classes offer the same features as Java, but in general they are more intuitive, easier to use and more concise compared to Java.

Let’s compare some basic operations.

String manipulation

String manipulation is a big chunk of the programming job.

Have you ever needed to check string references equality? String is more a Value Object than an Entity, we are only interested by its attribute not by its identity. So it is inconvenient that we cannot use the == operator in Java for checking equality. Thanks to operator overloading, in C# you can compare two strings either with the equals method or the equality operator. This seems insignificant but it is a frequent source of confusion in Java (we check this violation on our platform), it is even more error-prone because the equality operator can sometimes lead to the expected results due to string interning.

Regular expression constitutes a significant part of string manipulation; Regex manipulation is eased in C#, thanks to verbatim strings and named captures. Verbatim string helps prevent cluttering of the regular expression with escaping characters; named captures give names to group, making the regex easier to read.

Regex urlRegex =
  new Regex(@"\\b(<protocol>https?|ftp)://(<domain>[-A-Z0-9.]+)(<file>/.*)?");
string domain = urlRegex.Match("https://cockpit.kalistick.fr").Groups["domain"].Value;

File IO

File IO is a fairly common operation and should be painless. In Java, without third-party library this is not true. Java beginners often ask what it is the best way to read of file, they do not know if they need to use a FileReader, a FileInputStream, a BufferedReader or a Scanner.

// In C#
string s = System.IO.File.ReadAllText(path);

// Equivalent in Java
String s = null;
FileInputStream stream = new FileInputStream(path);
try {
  Reader reader = new BufferedReader(new InputStreamReader(stream)); // Use default encoding
  StringBuilder builder = new StringBuilder();
  char[] buffer = new char[8192];
  int read;
  while ((read = reader.read(buffer, 0, buffer.length)) > 0) {
      builder.append(buffer, 0, read);
  }
  s = builder.toString();
} finally {
  stream.close(); // Potential issue if this throws an IOException,
}

Of course with a third-party library, this can be done in one line (Apache Commons IO for example).

Date manipulation

// In C#
DateTime now = DateTime.Now;
DateTime nextWeek = now.AddDays(7);

// Equivalent in Java
Date now = new Date();
Calendar c = Calendar.getInstance();
c.setTime(now);
c.add(Calendar.DATE, 7);

(Use JODA Time for date manipulation in Java)

Concurrency

Before .NET 4, C# was behind Java concurrency-wise. But now it offers the same functionality than Java and even more.

// Parallel For
int[] numbers = { 2, 5, 8, 4, 7, 9, 13 };
int[] squaredNumbers = new int[numbers.Length];
Parallel.For(0, numbers.Length, i =>
  squaredNumbers[i] = (int)Math.Pow(numbers[i], 2)
);

// Parallel LINQ
var fibonacciNumbers = numbers.AsParallel().Select(n => ComputeFibbonacci(n));

To sum up, I find the .Net framework base classes easier to use and more intuitive, in general, than their Java equivalent but all the third-party libraries available in Java alleviates this point. (Apache Commons, Guava, Joda time…)

Good Artists Borrow, Great Artists Steal

Many C# open source library are a direct port of successful Java library. They have since evolved to take advantage of the C# benefits, promoting DSL-like syntax instead of XML configuration file, but at the beginning they were direct “rip-off” of their Java equivalent.

• Hibernate => NHibernate
• Spring => Spring.NET
• Log4J => Log4Net
• JUnit => NUnit
• …

Example of a “fluent” NHibernate mapping:

public class CatMap : ClassMap
{
  public CatMap()
  {
    Id(x => x.Id);
    Map(x => x.Name).Length(16).Not.Nullable();
    Map(x => x.Sex);
    References(x => x.Mate);
    HasMany(x => x.Kittens);
  }
}

<!-- Equivalent XML mapping -->
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
  namespace="QuickStart" assembly="QuickStart">  

  <class name="Cat" table="Cat">
    <id name="Id">
      <generator class="identity" />
    </id>  

    <property name="Name">
      <column name="Name" length="16" not-null="true" />
    </property>
    <property name="Sex" />
    <many-to-one name="Mate" />
    <bag name="Kittens">
      <key column="mother_id" />
        <one-to-many class="Cat" />
      </bag>
  </class>
</hibernate-mapping>

Frameworks: one vendor to rule them all

Desktop application

Once the platform of choice, the desktop is becoming less and less important with the rising of web application. Nevertheless, desktop applications are still significant and cannot be ignored.

For a cross-platform desktop application, you do not have much choice but to choose Java. But if your audience is Windows only you should consider using the .NET Framework. Two API are available: WinForm which is a wrapper around the old Win32 API and WPF which uses DirectX and provides vector graphics allowing elements to be scaled without loss in quality.

WPF employs XAML, a derivative of XML, to define the UI in a declarative way, allowing the developer to describe the interface and behavior without the use of procedural programming. The use of XAML provides a better separation of model and view and allows designers to contribute to the application development cycle more.

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Xaml Example" Height="290" Width="300" Background="#eee">
  <StackPanel Margin="10">
    <ScrollViewer Height="200" Width="260" Margin="0 0 0 10"
                  VerticalScrollBarVisibility="Auto"
                  HorizontalScrollBarVisibility="Auto">
      <TextBlock Text="{Binding TextContent}" Background="#fff"/>
    </ScrollViewer>

    <StackPanel HorizontalAlignment="Left" Orientation="Horizontal">
      <TextBox x:Name="TheLineTextBox"
               Text="{Binding TheLine, UpdateSourceTrigger=PropertyChanged}"
               Width="205"
               Margin="0 0 5 0"
               KeyUp="TheLineTextBox_KeyUp"/>
      <Button Content="Enter"/>
    </StackPanel>
  </StackPanel>
</Window>

Desktop application development is an area where the .Net framework shines.

The Web

For a long time while the .NET community was dragging and dropping controls onto an ASP.net page, the Java community was building highly scalable web application using one of many web frameworks available. Here is the difficulty… information overload. If you take a look at the list of Java web frameworks, you can see there are many of them to choose from, and each one requires pretty extensive research to understand.

Until 2008, Web development in C# was analogous to ASP.Net and Web Forms. The main purpose of Web Forms was to ease the transition to the web development for people with a desktop development background. Same skills are transferable between the two, for example you can handle button clicks with events and delegates like you will do in a desktop application and all of the complexity is handled by ViewState and PostbackModel. The flaw of this is that it tries to inject state into what should be stateless: the web. The beauty of this model is its flaw too: by simplifying web development it abstracts and hides the inner bolts from the developer and produces developers who don’t understand the basics. Clean applications with separation of concern are feasible with Web Forms but require more discipline, everything is done to push you into using the RAD tools.

On the other hand, ASP.Net MVC, the new web framework of Microsoft, is a more lower-level component, closer to the standard method of Web Development. It looks like the other MVC frameworks that could be found in Java (Spring MVC) or in Ruby on Rails.

Rich Internet Application (RIA)

Both Java and .Net have competitors to Adobe Flex and Air. JavaFX is the RIA framework of Java, but it never took off.

Silverlight is the one for .NET, it is like a subset of WPF aiming rich internet application. It uses the same tool Visual Studio, Expression Blend, the same UI syntax XAML and a subset of the .NET Framework.

These last four years, Microsoft have brought Silverlight to the fore, releasing a new version at a rapid pace. That way it manages to reach a penetration rate of 73% (June 2011), which is quite good but still low compared to the 97% penetration rate of Flash.

The problem is that Microsoft seems to have a change of mind and they are now gone full in the HTML5 bandwagon, leaving the Silverlight developers doubtful. That’s the problem with languages and tools lead by a unique vendor, you are dependent of its internal politics.

Mobile

Mobile development is the new battleground, and I am afraid that Microsoft has already lost, killed by Apple and Google. The choice of language and platform is more driven by adoption than by convenience. It’s sad because the tools provided by Microsoft for Windows Phone 7 development are very nice: C#, Silverlight, XNA, Visual Studio, Expression Studio.

To sum up, nothing that can be done in Java that cannot be done in C# but you’ll have less choice in your framework choice in the .NET ecosystem than in Java. This is bad per se but avoids the information overload and the scattering that can be found in Java.

“A workman is only as good as his tools”

A comparison would not be complete without the comparison of the tools. As important as the framework, tools can make a hard job seems easy and inversely.

Visual Studio, the IDE from Microsoft, is the official choice for .Net development. It offers the same features that can be found in a Java IDE and some more like IntelliTrace, a historical debugger that records all events and allows the code execution to be rewound for debugging (an equivalent exist in Java: Eclipse Chronon), but also an architectural and modeling module allowing to draw a dependency graph of the application and check them (A bit like what we do in the Cockpit with the technical architecture) and more… Unfortunately, all these features have a cost and Visual Studio is neither free nor cheap.

Open source IDE exist too: SharpDevelop and MonoDevelop (develop by the Mono team), they have less features than Visual Studio but evolve quickly. The good point is that, unlike Java IDE, they all share a common project file, so you can switch back and forth between them. In Java, you will have to use a Maven POM file to have a similar feature.

Write once, run…somewhere

“Write once, run everywhere” is the slogan created by Sun to promote the cross-platform benefits of the Java language. The same slogan cannot be used for .Net but the situation is not as limited as people may think, C# and .Net in general are not for Windows only.

Silverlight

As I have explained earlier in this post, Silverlight is the Rich Internet Application framework of .Net, Silverlight application can run on Windows of course but also on Mac and Linux (the Mono team develops the linux port, under the name of MoonLight, with the cooperation of Microsoft). Silverlight is also used for Windows Phone 7 development.

XNA

XNA is a set of tools for game development and management in C#. Targeting indie game developers, it allows them to develop games in C# for Windows, Windows Phone 7 and the Xbox 360.

Lumi – A game created with XNA

Mono

Mono is a free and open source project led by Xamarin (formerly by Novell) to create a .NET-compatible set of tools. Mono brings C# and the .Net framework not only on Linux but also on BSD, Solaris and even on the Wii.

The Mono team also develops MonoTouch that allows developers to create C# and .NET based applications that run on the iPhone, iPad, and iPod Touch devices, while taking advantage of the iOS APIs. As well as MonoDroid which is the equivalent of MonoDroid for Android devices and MonoMac for developing Mac OS application.

Netduino

Like for Java, the .NET framework comes in several edition:

• .NET Framework, equivalent to Java SE/EE
• The Compact Framework, equivalent to Java ME
• The Micro Framework, the smallest edition, targeting embedded device development. For example, a specific version of the Arduino (an open-source single-board microcontroller): the Netduino uses the Micro Framework.

It’s a wrap

In this post I have presented the .NET ecosystem which essentially offers the same features than Java but with a limited diversity/choice. Starting a project using .Net is more straightforward, you almost don’t have to search for a given solution. That can save you a considerable amount of time. But if the solution doesn’t fit your need, fewer alternatives are available.

In the last post of this series I am going to present the .Net community to see if it can match the very strong one of Java.

• Part 1: Differences in similarities
• Part 2: A brand new world

Delegate: Method as a first-class citizen

A delegate is a special type that defines a method signature. Delegates are like C function pointers with type safety that allow methods to be passed as parameters and stored in a structure or a class.

// Declaration of a delegate type
delegate string StringOperation(string str); 

public class Delegates
{
  public static string Reverse(string str) // doesn't support full unicode charset
  {
    char[] arr = str.ToCharArray();
    Array.Reverse(arr);
    return new string(arr);
  }

  public static void Main(string[] args)
  {
    StringOperation normalizeOp;

    // Creation of a delegate instance
    normalizeOp = Delegates.Reverse;
    Console.WriteLine(normalizeOp("abcd")); // dcba

    // Instantiate the delegate using an anonymous method.
    normalizeOp = delegate(String str) { return str.Trim(); };
    Console.WriteLine(normalizeOp("  abcd "));  // abcd
  }
}

To mimic this feature in Java, the developer will have to create a class implementation (generally an anonymous inner class) where one method performs the action.

interface StringOperation
{
  String invoke(String str);
}

public class Delegates
{
  public static String reverse(String str)
  {
    return new StringBuffer(str).reverse().toString();
  }

  public static void main(String[] args)
  {
    StringOperation normalizeOp;

    normalizeOp = new StringOperation(){
      public String invoke(String str)
      {
      	return Delegates.reverse(str);
      }
    };

    System.out.println(normalizeOp.invoke("abcd")); // dcba

    normalizeOp = new StringOperation(){
      public String invoke(String str)
      {
      	return str.trim();
      }
    };

    System.out.println(normalizeOp.invoke("  abcd ")); // abcd
  }
}

The ability to refer to a method as a variable or as a parameter makes delegates ideal for a lot of usage, delegates are used everywhere in C#, as event handlers, thread actions, callbacks in asynchronous programming, in LINQ…

Event

In a GUI environment, any number of controls can raise an event (button click, menu selection, completion of a file transfer). Other classes will be interested in responding to these events but the publisher of the event is not interested by how classes receiving the event will respond. C# provide a specific syntax to enable event-driven programming implementing the publish/subscribe pattern.

class Button
{
  public delegate void Action();
  public event Action Click;

  public void PerformClick()
  {
    OnClick();
  }

  private void OnClick()
  {
    if (Click != null)
    {
      Click();
    }
  }
}

class Program
{
  static void PerformAction()
  {
    Console.WriteLine("Work!");
  }

  public static void Main()
  {
    Button button = new Button();

    // Subscribe to the event
    button.Click += PerformAction;
    button.PerformClick(); // Work!

    // Unsubscribe
    button.Click -= PerformAction;
    button.PerformClick(); // Nothing
  }
}

In Java, there is no general mechanism for event handling, instead events are manually implemented with the observer pattern: anonymous inner classes are commonly used to implement the listener, allowing the developer to define the body of the class and create an instance of it in a single point in the code.

public interface ClickListener extends EventListener
{
  public void click();
}

public class Button
{
  protected EventListenerList listenerList = new EventListenerList();

  public void addMyEventListener(ClickListener listener)
  {
    listenerList.add(ClickListener.class, listener);
  }

  public void removeMyEventListener(ClickListener listener)
  {
    listenerList.remove(ClickListener.class, listener);
  }

  public void performClick()
  {
    onClick();
  } 

  void onClick()
  {
    Object[] listeners = listenerList.getListenerList();
    for (int i=0; i<listeners.length; i+=2)
    {
      if (listeners[i]==ClickListener.class)
      {
        ((ClickListener)listeners[i+1]).click();
      }
    }
  }
}

public class Program
{
  public static void main(String[] args)
  {
    Button button = new Button();
    button.addMyEventListener(new ClickListener() {
      public void click(EventArgs evt)
      {
        System.out.println("Work!");
      }
    });

    button.performClick();
  }
}

Lambda Expression: Delegate on steroids

A lambda expression is an anonymous function that can be used to create delegates. Syntacticly it is composed of three parts: an input parameters list, the lambda operator =>, and a method body. Thanks to type inference, you often do not have to specify a type for the input parameters: the compiler can infer the type based on the body and the underlying delegate type.

delegate bool Assertion(int value);

// Equivalent to (int x) => x == 42;
Assertion isUniverseAnswer = x => x == 42;
isUniverseAnswer(42); // true

One of the most important features of Lambda Expressions (and anonymous methods) is that they execute in the context of their declaration. Therefore, they can use the values of variables defined in that context.

List<User> FindAllYoungerThan(List<User> users, int limit)
{
  // The lambda expression uses the outer variable "limit"
  return users.FindAll(user => user.Age < limit);
}

Lambda expressions can be used to implement closures. Closures can be defined as functions that capture the state of the environment that is in scope where they are declared.

delegate void Action();

static Action CreateAction()
{
  int counter = 0;

  // Returns a delegate, the action is not executed here.
  return () => Console.WriteLine("counter={0}", counter++);
}

void Main()
{
  Action action = CreateAction();
  action(); // counter=0
  action(); // counter=1
}

LINQ’s awakening

LINQ (Language-Integrated Query) is a set of technologies based on the integration of query capabilities directly into C#. With LINQ, queries are a first-class language construct.

IEnumerable<int> query =
              from user in users
              select user.Age;

Query expressions are written in a declarative query syntax allowing filtering, ordering, and grouping operations. The same query expression could be used to query and transform data in from various sources: databases, datasets, XML documents, and collections. A single query can retrieve data from a SQL database, and produce an XML stream as output. The execution of the query is deferred until the result is requested. Deferred execution can greatly improve performance when manipulating large data collections with a series of chained queries or manipulations.

// 1. DataSource
int[] numbers = new int[] { 0, 1, 2, 3, 4, 5, 6 };

// 2. Query creation.
IEnumerable<int> numQuery = from num in numbers
                            where (num % 2) == 0
                            select num;

// 3. Query execution.
foreach (int num in numQuery)
{
  Console.Write("{0,1} ", num); // 0 2 4 6
}

There is no magic behind LINQ: at compile time, query expressions are converted to standard method calls using query operators.

IEnumerable<int> querySyntax =
              from user in users
              select user.Age;

IEnumerable<int> methodSyntax = users.Select(user => user.Age);

No more StringUtils with Extension method

It is rather common to have classes full of utility methods that mostly enhance the functionalities of some other classes (StringUtils, ArrayUtils…)

Extension methods enable you to “add” methods to existing types without creating a new derived one or modifying the original. They are called as if they were instance methods on the extended type. The extension methods will hang on the type, so they will be easier to find with completion than an Util class.

string reversed = "Example".Reverse();
reversed = StringUtils.Reverse("Example")

Extension methods are used for LINQ to add standard query operators on existing IEnumerable types (Select, Where, GroupBy, OrderBy, Average…).

Pass by reference

In Java, arguments to a method are passed by value; a method operates on copies of the items passed to it instead of on the actual items: a copy of the value for primitive type and a copy of the reference for objects. Because of that simple things like swapping two numbers in a method are not easily doable in Java (must use a wrapper or some arithmetic).

By default, it works the same way in C# but it is possible to specify that the arguments of a method must be pass by reference. This is particularly useful when you want to create a method that returns more than one object.

A common pattern in the .NET framework is the TryXXX pattern. For example methods int Int32.Parse(string) and bool Int32.TryParse(string, out int) use this pattern, Int32.Parse is used to convert a string to an integer. The TryParse method is like the Parse method, except that TryParse does not throw an exception if the conversion fails. It eliminates the need to use exception handling in case the string cannot be successfully parsed.

// Using Parse method, with exception handling
int quantity;
try
{
  quantity = int.Parse(input);
}
catch (FormatException)
{
  quantity = 0;
}

// Using TryParse
int quantity;
if (!Int32.TryParse(txtQuantity.Text, out quantity))
{
  quantity = 0;
}

This feature could also be used to improve performance when dealing with value type. When a value type is passed to a method its value is copied, if the value type is large (e.g. a 4×4 matrix includes 16 floats) it is better to pass a reference of the value type instead of a copy of it.

Matrix view = ...;
Matrix projection = ...;

Matrix viewProjection;
Matrix.Multiply(view, projection, out viewProjection);
// viewProjection = view * projection;

Partial type

.NET is big into automatic code generation: Visual Studio uses this for Windows Forms, Web service wrapper code creation. To facilitate the usage of generated code it is possible to split the definition of a class, a struct, an interface or a method over two or more source files. Each source file contains a section of the type or method definition, and all parts are combined when the application is compiled. That way one part of the type is edited by the code generator while the other part could be edited by the developer without the risk of the generator overwriting that code later.

// In file A
partial class HumptyDumpty
{
  private string name = "Humpty Dumpty";

  public void Rhyme()
  {
    Sat();
    Fall();
    TryPutTogether();
  }

  public void TryPutTogether()
  {
    string putTogether = @"All the king's horses and all the king's men
                           Couldn't put Humpty together again.";
    Console.WriteLine(putTogether);
  }
}
// In file B
partial class HumptyDumpty
{
  void Sat()
  {
    Console.WriteLine("{0} sat on a wall,", name);
  }

  void Fall()
  {
    Console.WriteLine("{0} had a great fall.", name);
  }
}

One useful usage is unit testing: the set of unit tests for a class is often much larger than the class implementation itself; the tests could be split into chunks using partial types. That way it is easier to work with the test suite but all the tests could still be run in one session (it is still a single test class).

Is that all?

Dynamic

Since version 4, C# provides a dynamic type. The main point is interoperability with COM API (Office API for example) and dynamic language such as IronPython or IronRuby (Python and Ruby running on the CLR). This feature will not be used by many developers in their day-to-day coding, but it can be useful and the cleaner way in some situation.

Example of C# code calling a python method through dynamic and IronPython.

ScriptRuntime py = Python.CreateRuntime();
dynamic random = py.UseFile("random.py");

int[] items = new int[]{0,1,2,3,4,5};

random.shuffle(items);

Null-coalescing operator

The null-coalescing operator ?? is used to define a default value. It is like a conditional binary operator tweaked for null value.

string address = user.BillingAddress ??
                 user.ShippingAddress ??
                 user.ContactAddress;

// Equivalent to:
string address = user.BillingAddress;
if (address == null)
{
  address = user.ShippingAddress;
  if (address == null)
  {
    address = user.ContactAddress;
  }
}

Automatic Resource Management

The using keyword provides an easy way to manage resource by handling resource disposal automatically.

string line = String.Empty;
StreamReader reader;
try
{
  reader = new StreamReader("file.txt"));
  line = reader.ReadLine();
}
finally
{
  if (reader != null)
    reader.Dispose();
}

This sample which uses the using keyword is equivalent to the previous one.

string line = String.Empty;
using (StreamReader reader = new StreamReader("file.txt"))
{
  line = reader.ReadLine();
}
Console.WriteLine(line);

Automatic resource management will be introduced in Java 7 as well (through java.lang.AutoCloseable interface).

try ( FileInputStream in = new FileInputStream("input.txt");
       FileOutputStream out = new FileOutputStream("output.txt"))
{
  int c;
  while((c=in.read()) != -1 )
    out.write();
}

And more

• Easy lazy iterator with yield
• Nullable type
• Unsafe code
• Conditional compilation
• …

It’s a wrap!

In this post I have showed C# features that differentiate the language from Java and which make C# a broader language with functional and dynamic pieces, with the objective of improving the expressiveness of the language.

In the following post I am going to describe the platform and infrastructure: framework, ide, build tool, continuous integration server…

• Part 1: Differences in similarities

Java and C# are more alike than they are different: both are curly-bracket languages like C and C++, both are statically, strongly and explicitly typed, both are class-based object-oriented, both are designed with runtime compilation in mind and both use garbage-collection.

In this post, I will focus on differences about common features that they share.

Unified type system

In Java the primitive types (byte, int, bool, float, char…) are special, they are not object-oriented and do not share a common ancestor with reference types. But they do have class type wrappers, that can be used to represent them and plug them in the Object hierarchy (i.e. Integer for int). This choice was made to improve performance.

On the contrary, C# has a unified type system in which all types derive from a common root type: System.Object, even the primitive types. So all types implement the Object methods (ToString, Equal, GetHashCode…), and you can do things like 3.ToString(). Mixed with extension methods this could provide nice dsl-like syntax :

TimeSpan workingTime = 7.Hours() + 30.Minutes();

The beauty is that value types are just as efficient as Java primitives, as long as the developer use them as values. Only if he tries to treat them as objects do they become heap allocated, through boxing/unboxing.

Explicit virtual methods

In Java all methods are virtual by default (although they can be sealed by using the final modifier to disallow overriding) while in C# they are not. To make a method virtual in C#, the programmer must explicitly declare it virtual using the virtual keyword.

There are several reasons for this choice, the first one is performance: there is a performance overhead associated with virtual methods as they cannot be inlined normally and require an indirect call via the vtable. (Sun JVM implementation implements inlining of the most commonly called virtual methods). The second and more important issue is versioning: C# is designed so that versioning between base and derived classes in different libraries can evolve and maintain backward compatibility. For example, the introduction of a new member in a base class with the same name as a member in a derived class is completely supported by C# and does not lead to unexpected behavior. The last one is readability: the developer intent is clearly stated. In Java, if the Override annotation is not used you never know if the developer intent was to override the method or not.

class Meme
{
  public virtual void Spread() {}
}

class ThreeHundred : Meme
{
  public override void Spread()
  {
    Console.Write("This is sparta!");
  }
}

class Dbz: Meme
{
  // Not a method override
  public void Spread()
  {
	Console.Write("It's over nine thousaaannnd!");
  }
}

True Generic

Regarding generics, Java and C# show a syntactical similarity, but when you look under the hood they have deep differences.

Java generics are implemented in the compiler only; the runtime has no knowledge of the generic type system. Instead, a process called type erasure transforms generics classes and methods during compilation: all generic types are replaced by their raw version and casts and checks are inserted in client code. The resulting byte code will contain no references to any generic types or parameters. Java generics are a syntactic sugar, they don’t get you any of the execution efficiency.

C# generics are not a language feature only, they are implemented in the CLR (Common Language Runtime, equivalent to the JVM) as well. During compilation, generics are verified for correctness, but the generation of the implementation is deferred to class-load time. Code invoking generics are fully compiled and can safely assume generics to be type-safe. This is called reification. Unlike with Java, there is no need to inject casts or type-checks. Generic types and methods can be constructed with both reference (classes, delegates, interfaces…) and value types (primitive type, struct, enum…)

The benefits of C# implementation are performance improvement (no cast and no boxing/unboxing of value types), deep type safety verification and reflection capability.

public void AwesomeGenericMethod<T>(T t) where T : new()
{
  T newInstance = new T (); // Causes a type creation error in Java
  T[] array = new T [0]; // Causes generic array creation error in Java
  T defaultValue = default(T);

  Type type = typeof(T);
  List<T> list = new List<T> ();
}

// Generic with same name but a different number of generic type
public void AwesomeGenericMethod<T,U>(T t, U u) where T : new()
{

}

Mark Reinhold (Chief Architect of Java Platform Group at Oracle) talked about reification at Devoxx 2011. But this feature is still not planned for next major releases of Java.

Farewell checked exceptions

Exceptions in Java and C# fairly work the same way, there is only one major difference between the two:  Java contains the notion of checked exceptions.  In Java you can declare throws ExceptionType in the method declaration, this forces any callers of that method to handle the exception.  This is a great idea on paper but in practice it tends to be an annoyance more than anything, bringing new issues:

• Versioning: adding a new checked exception to a method declaration in a new version breaks client code; it’s like adding a method to an interface. In version one you create a method foo that declares it throws exceptions A and B, in version two you add a bunch of features and throw exception D, this is a breaking change because existing callers do not handle this exception.
• Scalability: in large application with a lot of dependencies, the number of exception grows exponentially and people will often shunt the feature by throwing the generic Exception or use empty catch block.

The idea behind checked exceptions is great but they tend to intrude to much, specially in big application. That’s why there is no checked exception in C# or any other mainstream languages: it’s up to the developer to handle them.

Double rainbow accessors

Java uses naming convention for its accessors and modifiers (i.e. getAddress, setAddress, isValid…). In C#, accessors and modifiers are built-in; with properties no need to write getters and setters, everything looks like a direct field access, even if it isn’t. (many languages uses the same idiom, by the way)

class Meme
{
  // A private backing field is created by the compiler
  public string CatchPhrase { get; set;}
  public string URL { get; set;}
}

Meme meme = new Meme();
meme.CatchPhrase = "Rick roll'd";
meme.URL = "http://www.youtube.com/watch?v=EK2tWVj6lXw";

// Equivalent in Java
class Meme
{
  private String catchPhrase;
  private String url;

  public String getCatchPhrase()
  {
    return catchPhrase;
  }

  public void setCatchPhrase(String catchPhrase)
  {
    this.catchPhrase = catchPhrase;
  }

  public String getUrl()
  {
    return url;
  }

  public void setUrl(String url)
  {
    this.url = url;
  }
}

When you declare a property as an auto-implemented one, the compiler creates a private, anonymous backing field that can only be accessed through the property’s get and set accessors. It brings consistency: the field is always used via the accessors even within the class and it looks cleaner and shorter!

A special kind of accessors exist that doesn’t exist in Java: the indexer; it is like a get/set with a parameter. C# collection like Dictionary (equivalent to Java Map) use indexer :

var keywordsMapping = new Dictionary<string, string>();
keywordsMapping["super"] = "base";
keywordsMapping["boolean"] = "bool";
Console.Write("Java => C# : {0} => {1}", "super", keywordsMapping["super"]);

You Say I’m Crazy, I got Your Crazy! You’re nothing but an Initializer!

You often has to create an object and initialize it right after, this can be done with constructor if one is available. Otherwise you has to create the object and then call the different setters.

Object initializers let you assign values to any accessible fields or properties of an object at creation time without having to explicitly invoke a constructor.

Meme leeroy = new Meme {
	CatchPhrase = "Leeroy Jenkins",
	URL = "http://www.youtube.com/watch?v=LkCNJRfSZBU"
};

It works with collection too:

List<int> digits = new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Dictionary<string, string> keywordsMapping = new Dictionary<string, string>() {
	{"super", "base"},
	{"boolean", "bool"},
	{"import", "using"}
};

Verbatim string

Escaping characters in string literal is a real pain, it clutters the string meaning, especially with Regex! In C# verbatim string allows backslashes, tabs, quotes and newlines to be part of a string without using escape sequences.

string pattern = @"\d{3}-\d{3}-\d{4}";
string input = @"Multiline string
   325-532-4521";
Regex.IsMatch(input, pattern, RegexOptions.Multiline);

It’s a wrap

In this post I have showed that despite its similarity with Java, C# is meant to make developers life easier, to ease their burden (and these are only samples among others). Not too bad for a copycat!

Java developers have brought responses to these lacks in their favorite language by introducing new scripting languages on top of the JVM. For instance, Groovy has most of features presented here. But Java language still does not change!

In the following post I am going to describe the totally different features that bring C# to another level of expressiveness and effectiveness: lamda expression, LINQ, dynamic, extension methods...