Testing through the Credit Crunch - Part 4 - Value Open Source

By now you will have hopefully realised that running a Test Department doesn't have to be expensive. We have seen that by making the entire company responsible for the quality of the product we take the strain off us doing the developers jobs and lets us find those show stopper bugs.

In this post I am going to discuss why you should value open source tools to automate finding those showstoppers.

Lets start at the small thing to be tools we need at the beginning:

Continuous Integration

How many time in the past have you released something and then suddenly have to roll back the release because not everything works together. Continuous Integration Servers get code out of the source repository. I am a big fan of Subversion as a source reprository, which just happens to be open source!

The top CI server application out there are CruiseControl, Cruise Control.NET, Hudson and TeamCity. 3 of those 4 are Open Source. The one that is not open source, TeamCity, requires a you pay for a licence if you want all the bells and whistles. You should be able to manage on the free version of TeamCity if that the one you decide on.

One of the most important features of all these tools is the ability to automatically run the unit tests that have been created by the developers.

Unit Testing

The de facto testing tools for Unit Testing are NUnit, JUnit and TestNG for .NET and Java. There are loads more out there, like unittest for python, that are used all the time. These tools are great for integrating into Continuous Integration Servers.

In the 2nd post of the series I mentioned that having unit tests allows us to have a safety net to work against. The CI servers will run every developers unit test. This allows developers to do a check-in/commit, once their tests pass, and then get the rest of the tests run. This means that if you make a change you will find out if you have by accident broke something. You will learn to appreciate this safety net but make sure that you don't become lazy and use that as your only testing.

Functional Testing

Web applications have the largest amount of Automation tools for functional testing. Since I also work in this industry I will be very biased towards the following applications.

• Selenium
  Selenium is slowly becoming the test tool of choice for Rich Internet Applications. Selenium allows you to write functional tests against AJAX applications. Selenium is used by the top Internet application companies and Agile Consultants.
  
  Its developed using JavaScript and can work in all Browsers on any OS. As you would have noticed I am a big fan!
  
• Watir
  Developed in Ruby its has a very good following. Test Scripts need to be developed in Ruby and you just import Gems for the Browser that you want to test.
  
  I found that it needed a lot of work to test multiple browsers compared to Selenium. I know some people would say its easier to use that Selenium. I guess its down to the user.
  

Acceptance Testing

More and more companies are starting to use acceptance testing tools to capture their requirements. Acceptance test frameworks can all integrated into Continuous Integration Servers. They take a plain text requirement and turn it into a Test Fixture.

• Fit
• FitNesse
• Concordion

The main tool for acceptance in my opinion is a manual tool commonly known as the customer. Remember that customers are both internal and external to the company! End users are the best acceptance testers as they are the subject matter experts and spot bugs quite quickly.


In the next post of the series I will discuss Visualization of Testing

Testing through the Credit Crunch - Part 2 - Test Driven Development

In the last post of this series I discussed briefly about Technical Debt and how Test Driven Development can help in dropping the debt and dropping the amount of interest gained over the life of the product.

Test Driven Development is the concept that you write your tests before you write your code. Once your code is finished you refactor with the safety that your newly created test will prevent any stupid bugs that you could have introduced. It's what the TDD community call Red-Green-Refactor. Now to most people writing tests first sounds stupid, "How do you know what your code is going to do until you have finished coding it?"
My retort tends to be "You know what you are expecting back from the call. Your test needs to be really small and since an Assert is a test, Assert what you are expecting your method to return! Image that your code exists and test against it." Below is an example of a small test and when writing tests we should try keep them as small as we physically can.

[Test]
public void creditcrunch_Test(){
int FutureTechnicalDebt = 100;
Assert.LessThan(FutureTechnicalDebt,TechnicalDebt.Current);
}

So we know that we need tests first to give us a good safety net for writing our code.In Technical Debt terms we have spent a little less to create/run and report on the test and we prevent anyone else breaking our code. Cost-- and Interest-- which is what we want. Running the test above will fail because there is no code to run it against. Write some code to make it pass if you have the time.

The other reason why developers are starting to like TDD, other than the removal of the ear ache that testers would give them about throwaway builds, is that challenges them to think about the interface into their new object. We have all sat down with the keyboard in front of us, tea/coffee next to us and found that someone has changed the interface your were developing against! Queue the expletives! $*@%*$£ !@)@)£)&! Luckily for us we have good Test Driven Developers who have have discussed the interface and we by proxy prevented interest being added to our debt. Interest--! Communication is key in Test Driven Developments, especially when it comes to interfaces because there may be some integration bugs that will creep in without you realising!

Knowing what the Interface is going to look like is has another major benefit. Mocks and stubs! If we know what the interface to an assembly is and how its going to react we can write tests to test our code and when it needs to speak to the other assembly, which may not have been created yet or makes our tests run slowly like accessing a database or filesystem, we can return the results back that we want our code to handle using one of them. This could be exceptions,dodgy data or good data. Testing those code paths means we can increase our code coverage therefore increasing the size of our safety net! It will also mean that our tests run a lot quicker because we don't have to interact with slow drives or have anyone elses tests interfere with our data. Cost-- and Interest--.

So by creating this safety net we have prevented stupid mistakes creeping into our code. Its these stupid mistakes that could cost our team/company a lot of money. Since companies don't have much money it could mean your job!

The graph below shows how by doing the, what I call, simple things we have brought down the technical debt that we could potentially owe. NOTE: The values used are just arbitary values I found on the internet with a little searching.

In the next post in the series I will discuss Virtualization and what the it can mean to you as  a tester!

Testing through the Credit Crunch - Part 1 - Development Environments

The credit crunch has gripped the world and not so long ago Gartner suggested that the investment in technology was going to drop. They have dropped the increase in spending from 5.8% down to 2.3%. This may not seem a lot but when companies spend millions on IT each year it adds up very quickly. Unfortunately past experience has shown that testing departments are the ones who suffer first.

More employers are predicting a rise in redundancies in the UK and the other week a politician predicted a run on British Pound.

This doesn't mean all doom and gloom for IT professionals. Over the next few weeks I am going be writing a series of posts with some best practices that I have found. Lets start this series by discussing the Environments we build and test software.

Environments

This is a very ambiguous term so lets split it into the 2 main things I mean. Development Methodology and Testing Environments.

Development Methodology

When creating products it is starting to become common practise to follow Total Quality Management (TQM). The idea is to make sure that quality is in every process of the organisation. By moving to your company to this principle you will be adding confidence to your product to all stakeholders. More confidence in your stakeholders will mean that your department will get a little more funding and since its the credit crunch it must be good!

A lot of companies actually practise this without realising it. The main thing to take away from TQM is that everyone in the company has a part to play in the quality of the product that is delivered!

Agile or Not!

My first few jobs were at financial institutions and thought it was normal to do testing at the end. I worked as a WinRunner Automated Tester. I then started working on some Open Source projects in Java and was asked "Can we see your unit tests? Did you use JUnit?".
I answered quite sheepishly "I tested it by checking that it did what it needed. I don't have any JUnit tests."

Obviously my code got rejected because it wasn't neat and didn't have proper unit tests. There was a few other issues that they raised and to be honest if I was doing the code review I would have rejected it too!

Now I work for an ASP/ SaaS and we do a little Agile. I have been able to see the value of being agile while developing software. The main thing that I have learnt is that Technical/Design debt is something that is inherently low in an Agile Evironment.

Technical debt is the idea that when you release software you go into debt. If you have cut corners it will affect the level of debt you have. If you leave these items in your code it will start gaining interest on your debt. So if you have any TODO's in there that is interest on your debt. If you have poorly designed interfaces then you have added interest on your debt. Putting testing at the end of a project will definitely add interest to your debt! Doing tests at the beginning of the development process will bring down the "interest" accrued against your debt in the development process.

So to help us get through this credit crunch we need to bring down the debt in our software. The best way to do this in my opinion is to achieve this is to move your development team to a Test Driven Development way of thinking. As I said above if you place your tests earlier in the process you will lessen your technical debt. The simple rule when it comes to testing is the earlier you test the cheaper it is to solve bugs. So putting in automated tests at the beginning of the development process will go far in bring down your actual development costs for that project but also for future developments.


In the next post I will discuss further the value of Test Driven Development.

.Net Gem - How to Unit Test Internal Methods

I have recently started redoing unit tests for bit of code at work and came across a internal methods and classes that needed to be tested.

This posed a question of: how do I access the internal methods and classes to test them properly from an external assembly?

I found this little gem that a lot of the developers where I work had not heard of, this doesn't mean that its not common knowledge but thought I would share it a little more.

I have put a scenario below of how it might work.

Being a good TDD developer you decide that you want to write your unit tests for an internal method. You create your .Net Class Library structure so you know what your tests need to call to do your asserts. It may looks something like the image below.

So now you want to start writing your tests and notice that your intellisense is not bringing up your internal class. So what do you do next?

Open the AssemblyInfo.cs file that is in your Properties folder. Add the line [assembly:InternalsVisibleTo("Unit.Tests")] somewhere near the top.

Now your Internal Classes and methods are only visible to Unit.Tests assembly.

Your start writing your unit tests and intellisense should be playing Mr. Nice Guy and we should see something like below.

I hope that it has been useful!