.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!

Are regression packs still worthwhile?

Recently I was on forum and noticed the thread "Why do we do Regression testing?". In it the person was complaining about their company's regression pack and asking if it was worth the effort of fixing it?

My answer was a little quick off the mark. I replied saying "Definitely! Its the backbone for each and every build!". But then this got me thinking, How many testers out there DO NOT practice Agile development? How many testers DO NOT work in an environment where automation of tests is 2nd nature?

I do not ask this question in a malicious way, I genuinely would like to know. When I go to SIGiST there are a number of questions in the presentations/workshops by people who have not worked in an Agile environment and, to be honest, seem scared by it. These are the same people when you mention something like "Continuous Integration" and they get that deer-in-headlights look on their face.

This leads me to my next question; Is there a "Rich get richer, Poor get poorer" divide happening in testing? People in conferences mention that the lines between development and testing is blurring. It's called grey-box testing. But your average manual tester in a large non-software institution (Banks, Insurance Companies, etc) have got their "break" in testing by being seconded to the test team for a project and never wanted to leave their secondment. They may not have been given opportunities to learn how to program or may not even have heard about concepts like Agile, TDD and all the other new ways testers do their jobs.

To these people; the answer to my original question is still the same: "Yes! Definitely! Otherwise things that used to work may not work anymore. I would also suggest trying to automate the regression pack as much as possible so that you can concentrate on making testing more efficient. Try automate as much as possible so that you can concentrate on doing testing on those hard to test areas. Quality of software is still the main objective of testing."

Tester 2.0 - Definition of an Agile Tester

I have been to a number of SIGiST Conferences over the last year and have always been impressed by the calibre of the speakers there. There has been a theme lately talking about Agile Development and Agile Testing but the thing that always seems to missing is someone giving their interpretation on Agile Testing. To actually describe what an Agile Tester is! And what they should be doing.

Below I am going give my opinion of what an Agile Tester by describing skill set needed.We are after all only as good as our skill set! I am going to rate them from 1 to 10 with 10 being needed and 1 being desirable.

Skill	Score	Reason
Creativity	10	A good tester needs to be extremely creative when trying to test applications. Developers like to think that they are clever and get all the bugs before its released. Unfortunately this is not true when a tester starts being creative in the way they test the application and breaks it very quickly!
Innovation	10	A good tester needs to be able to innovative with the tools that they have. An example would be in SaaS(Software as a Service) companies who constantly striving to be the next big thing and competing against the likes of Google, Microsoft, Salesforce, etc. This drives innovation in development which means that it drives innovation in testing!
Test Automation	9	Every Agile tester needs to be able to do some form of automated testing. I am not saying that the tester must know how to use every tool that is out there but they need to understand how to create the automated tests.
Exploratory Testing	7	Agile Testing tends to mean Exploratory testing. I know that some people will disagree with this but because testing tends to happen on the fly and appears ad hoc but it isn't. Exploratory testing does have a set of rules that need to be adhered and will mostly bring a number of bugs to the surface just as well as normal scripted testing.
Communication	7	One of the main pillars of Agile Development is communication. This is very important in my opinion because a good tester must be able to communicate bugs to developers and requirements to end users. A good tester will also be able to challenge technical architects on their ideas. I know the last sentence can be very hard to achieve in large organisations but it doesn't mean that you can't send them an email to make suggestions.
Development	5	An Agile Tester should not be afraid to look at a developers code and if need be, hopefully in extreme cases, go in and correct it. I am not suggesting for one minute that they must be able to code entire applications but must have the confidence to look at a bug, spot the error in the code and either write a unit test to break it or point out the line where they think the issue is. An example of this is where doing Paired Programming with one developer we shaved of nearly 70% off the time it took to run a unit test test suite just by doing a one line change to their tests which got them to make one other small change.
Ability to work in pairs	3	I am a fan of being able to knock ideas off each other. I wouldn't do paired programming all the time but I like the concept and how it seems to get things done properly with little fuss.

This is not a comprehensive list but these for me are the most important things. Tester 2.0 is something that a number of testers need to strive for if they do not want to get left behind. There is a definite blurring of lines between development and testing. Gone are the days of "I have finished my part, over the wall it goes!". There is also a move to more "Grey Box" testing because of this blurring.

Selenium Grid - Why is this the way of the future?

Update: If you are looking for a Selenium Grid Tutorial I have put it here

I have been working with Selenium Grid since Philippe Hanrigou and others at ThoughtWorks released it at the end of last year. I knew then that it was going to become the standard way for automated GUI web application testing.

As an application it has great potential since it is has all the best bits of Selenium but it does multiple browsers in parallel. Suddenly your testing that used to take n units of time to run are taking 1/n to run. As a practitioner you can get things done quicker, as a manager you can get things done for cheaper! Everyone is a winner.

The other thing that makes the grid work well, and this is a thing that makes Selenium Remote Control work brilliantly, is the ability to use any language to control the test. People use Java, Ruby, .Net, Python and many more to create their test scripts and run it with the appropriate client. If you have the appropriate client application like TestNG for Java or DeepTest for Ruby or PNUnit for .Net you can start running tests with one script in parallel. The one limitation toof using these test tools is that you only really have one browser application, like Firefox, being tested at a time. This is because you only have one instance of the Selenium object in your code.

The way that I have got around this is to have many instances of the Selenium object in my code that each control a certain type. This type could be Internet Explorer 7 on Vista or Firefox 2 on XP.

An example of this would be (Note: I use c# to create my tests and then run them with NUnit)

[Setup]
public void setup(){
//Vista IE7 Instance
VistaIE7selenium = new DefaultSelenium("hub", 4444, "IE7 on Vista", "http://testserver");

//XP Firefox2 Instance
XPFirefox2selenium = new DefaultSelenium("hub",4444 , "Firefox2 on XP", "http://testserver");
XPFirefox2selenium.Start();
}


[Test]
public void GridTest(){
VistaIE7selenium.Open("/index.html");
XPFirefox2selenium.Open("/index.html");
}

As you can see it has the ability to create multiple instances of Selenium and then run them. This then leaves the handling of the Selenium Remote Control up to the Grid. As Philippe says, "It allows you to gridify your tests".

The negatives of Selenium Grid is that its still a work in progress. I know, thats hardly a reason to call it a negative. There are also a number of bugs but its growing section of OpenQA.org so give it a chance! I have 7 Selenium Remote Control instances running against my Grid (all virtualised with MS Virtual Server and WMWare) and I haven't had many issues. I have hooked Selenium Grid into our CruiseControl.NET server to test all the different browsers. I still have a lot of work to do with this but I know that it will be worth it in the end!

If you want to automate web testing and you want to do it efficiently use Selenium Grid! It will make your life a lot easier!

Is documenting test processes a bad idea in an Agile Development Environment?

I work in a smallish development team in Southampton as some of you know. There are other development teams in the group in United Kingdom and in France that all fall under the same group of companies of different sizes.

The unfortunate problem that we have is that there isn't a properly documented process for getting everything in place and ready for each testing cycle. Once we have everything ready we have another problem that I will hopefully discuss in a future posting.

This is where I had the thought "Is documenting test processes a bad idea in an Agile Development Environment?". If you have worked in an office with ISO9001 accreditation you will know that everything needs to be documented or if you have worked in a Six Sigma office you will have noticed that you have to put everything you do in a database so the "Black Belts" or "Master Black Belts" can see areas that need improvement.

So back to my question, "Is documenting test processes a bad idea in an Agile Development Environment?". My answer is definitely! And I am going to admit this is a fairly biased answer having started my career in large financial institutions where I was taught that everyone is expendable but their process knowledge isn't. This means that everything needs to be documented. However my thoughts on this is that things need to documented and followed to a point as long as that point does not impact on the creativity of the software developers and the testers.

Its this creativity that allows people to come up with new and exciting ways of developing and testing. Tools like the xUnit and Selenium and many more have come from this creativity. This then needs to be balanced with some form of Total Quality Management (TQM) so that everything can be reproduced if and when needed.

Documented processes can't be completely wrong, if they were then large companies like IBM, Citrix and Microsoft would have never got to where they are now!