One of the practices I try to “sell” to anybody involved in software development, is the practice of Test-Driven Development. Once you have practice TDD, you never go back. It is a practice with so much reward and joy, I feel uneasy when I wrote real software without using it.

Thanks to a tweet by @jjfalcon, I discovered this example, in Youtube, by user objarni. He is using Ubuntu, programming in Python, and using pyTDDemon to see inmediatly the results of test.

Note the red-green-refactor cycle, the minimal code that is added in each tests (only to have green in test, including cheating in return values), refactoring the test if there are duplicated code, microdesign decisions, etc… Nice work!

I tagged more videos about TDD, in my delicious:

http://delicious.com/ajlopez/tdd+video

All about TDD

http://delicious.com/ajlopez/tdd

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

There are lots of testing frameworks that are present in the internet now a days and one of them is NUnit. It is basically easy to use and is a very useful tool. I’ve tried to integrate it in one of our projects in replacement for the Microsoft testing framework. Everything went well and a few test fixtures was made. The problem occurred when we tried to perform integration testing where in we need to access the database to perform model testing. This is prior in using dbunit for model testing.

The issue was, the connection cannot be created. To add more insult to the injury, the error didn’t came that easy to be figured out. We need to dig the stack trace to figure out what went wrong. It is a minor issue yet it took a bit of our time figuring it out. And after a few hours of testing, here’s what we found out.

NUnit does not read the project’s config file(web.config), as opposed by .net built-in test enviroment which uses the actual config file. NUnit has its own configuration file which can be either NUnit-console.exe.config or NUnit-gui.exe.config. Yet this configuration files does not act as configuration files for the project but rather config files for the NUnit itself.

When NUnit runs your test, it creates a separate AppDomain in order to give them a different set of directories for finding assemblies and a different configuration file from NUnit itself. NUnit tells the .net framework the name of the configuration file to use. You can refer to the following step for setting the project configuration file path.

1. Create a new NUnit project for your application.
2. Click Project tab then Edit…
3. A new window will appear, set the Configuration file name on the config file name textbox.
4. Save and close the window and run your test.
5. Create the config file on the bin folder and set your config initialization.

The above process works if you create a specific NUnit project, but if you directly load a .net project assemly, such as myapp.dll(usually located in the bin folder), the config file will automatically be named myapp.dll.config. You can now copy your myapp.dll and rename it ti myapp.dll.config and set the necessary values needed by the test application.

Lastly, If you use NUnit’s Visual Studio support to load a Visual Studio project or solution, such as mytests.csproj or mytests.sln, the config file must be named mytests.config. In all of these cases, the config file must be in the same directory as the assembly or project that you are loading.

If you aren’t sure whether your config file is being used, a good trick is to put a special setting in it and write a test to see if that setting can be retrieved. For example,


[Test]
public void CheckConfigFile()
{
Assert.AreEqual( "checkconfig", ConfigurationSettings.AppSettings["configCheck"] );
}

Paul,

I’ve been searching for a TDD framework in C, and your post cracked the issue for me, made me look for/use the right search terms.

In the meantime, I found something that extends your list a little. Because of your helpful hints, I want to give back (Unfortunately I didn’t try to get over hurdles (log in?) to post a comment on your blog, hence I do it here on my own):

• CUnit seems to be kind of ‘that’ C TDD framework
• Wikipedia/XUnit looks like a good anchor point from where to get the search for any language’s TDD framework really started
• and finally, Wikipedia/List of unit testing frameworks looks like a good survey on at least C TDD frameworks.

(I hope, this is a good contribution of mine to your posting.)

Best,
dagobart

My Point2 workstation recently received a monitor upgrade; the old pair had had served me faithfully for many years, but they were worn out. So I am now the proud user of a pair of shiny new widescreen monitors.

The new monitors are much nicer than the previous monitors, and they are also a much higher resolution (1920 x 1080 vs 960 x 1280). Using them is a very enjoyable experience, but at first it seemed like the widescreen aspect ratio was wasting a lot of horizontal space:

Before: my widescreen monitor with a single file open

Then a few days ago, in the middle of a pairing session, I discovered IntelliJ’s split screen feature. In my opinion, the combination of a wide screen monitor and split screen is a killer feature for TDD. If you assign your test code in one pane, and your production code to another pane, you can see your test and production code at the same time:

After: my widescreen with two files open simultaneously

To activate split screen choose “Split Vertically” from the Window menu, or right click on a document tab and choose “Split Vertically”.

IntelliJ works very nicely with this split screen configuration; intentions, “Go To Declaration”, and refactoring shortcuts jump nicely to the appropriate screen. Being able to read test and production code at the same time without clicking a button is especially valuable when pairing, as each half of the pair can be reading a different file. One important caveat: this only works correctly if each file is only open in one pane, and IntelliJ doesn’t enforce that for you.

Some of you might wonder what the second monitor is used for, and the answer is pair programming. We pair program all the time at Point2, so I run the two monitors as mirrors. I’ve also added an extra keyboard and mouse, and the combination allows each member of the pair to see exactly what’s going without craning their necks or stretching. It’s a really nice feature for a pairing station.

My pair-friendly workstation. My keyboard and trackball are on the left, and the developer pairing with me has their own keyboard, mouse, and monitor on the right. Either of us can drive without any inconvenience.

By: Sean Reilly

My previous findings regarding the testing of public methods versus private methods opened the door to allow me to better understand that the mindset of a developer performing unit “testing” is different from the mindset of a developer “specifying program behaviour through the mechanism of automated test methods”. The difference is subtle but important.

In the concept and terminology of Behaviour-Driven Development, Design, Analysis and Programming, the resulting program code is simply an implementation of previously specified behaviours. Those said behaviours are initially defined at the business level via the process of requirements gathering and specification, and can be expressed in the business’s language as a set of scenarios and stories. These requirements can then be further analysed and broken down into logical and physical program specifications.

Regardless of whether a test-first approach to development is taken, by the end of the construction task, there should be a set of unit test cases (automatic and/or manual) that were successfully executed and that covers all of the logic specified in the program specification. In other words, by the end of the construction task, the developer has verified that the program behaves as specified.

Typically a program’s specification is written in a document somewhere which is divorced from the location of the actual code -  so great discipline and effort is required in order to keep the specification and code in synch over time. Depending on the company and financial constraints of the project, this may not be feasible.

However, what if we could remove this boundary between the document and the code?

Automated test cases serve a number of useful purposes, including:

- Behaviour verification;

- Acting as a “safety net” for refactoring code;

- Regression testing;

- Professional evidence that one’s own code actually does what one has said it does; and

- Acting as sample code for other developers so they can see how to use one’s code.

What if the automated test assets were the actual living program specification that is verified through the mechanism of test methods?

This concept has been recognised before, and the libraries JBehave, RSpec, NBehave and NSpec have been the result. While I honour the efforts that have gone into those libraries and the ground-breaking concepts, I do not necessarily like the usage of them.

In fact, all I want is to be able to express my specifications in my MSTest classes without the need for a different test runner or the need for another testing framework. In addition, I want other team members to easily grasp the concept and quickly up-skill without too much disruption.

While a DSL might be more ideal under these circumstances, I write my automated test assets in the C# language. Working within that constraint, I want to express the program specification in test code. With special note to the agreeable BDD concept that “Test method names should be sentences” I devised the following structure for expressing program specifications as automated test methods.

namespace |MyCompany|.|MyAssembly|.BehaviourTests. |MyClassUnderSpecification|Spec

{

public class |MyPublicMethodUnderSpecification|Spec

{

[TestClass]

public class Scenario|WithDescriptiveName|

{

[TestMethod]

public void When|MoreScenarioDetails|Should|Blah|

{

// Test code here

}

[TestMethod]

public void When|AnotherSubScenario|Should|Blah|

{

// Test code here

}

}

}

}

This structure allows for the naming of the public method that is under specification (the parent class name), a general scenario with a description of the context or given setup required (the nested MSTest class name), followed by the test method names which further narrow the scenario and provide descriptive details of the expected behaviour.

The test names look neat in the Test View in Visual Studio (when the Full Classname column is visible), and are readable just like their corresponding stories.

The full class name in this instance would look like:

|MyCompany|.|MyAssembly|.BehaviourTests. |MyClassUnderSpecification|Spec. |MyPublicMethodUnderSpecification|Spec +Scenario|WithDescriptiveName|

With automated spec/test assets/classes structured in this fashion, instead of developers performing unit “testing”, developers can instead embrace the mindset of “specifying program behaviour through the mechanism of automated test methods”. In turn, developers should be more focused on their tasks and it should also lead to higher quality code bases.

Oh, and I haven’t even mentioned how much easier it would be for a developer new to a project to learn and understand the code base by looking at the test view and reading all the scenarios that have been specified and coded…

This makes me want to use Flash Builder 4!

Introduction to Unit Testing – Activetuts+

Unit testing is relatively new to ActionScript projects. Although FlexUnit has been around for a while it wasn’t intuitive to set up and there were a lot of inconsistencies with the documentation. Lucky for us, FlexUnit is now built into Flash Builder 4. Although the documentation is still sparse, this tutorial will be a good primer for setting up a Test Suite, going over several unit test examples and showing how to run/analyze them.

I just want these in one place for future reference, in no particular order except the order they are open in tabs in Firefox at the moment…

Software Testing Geek -Software Testing – Selenium IDE, RC Tutorial & Workshop

Examples « Watir

Home – mozrepl – GitHub

Software Testing Geek -Twill – Simple Web Automation Tool in Python

3hv » Blog Archive » Cucumber and WATIR: kick-starting your testing

Home – cucumber – GitHub

Watir

brynary-webrat :: gitrdoc

PHP – cucumber – GitHub

A relatively new concept of coding is becoming more mainstream; what do you think of writing test code prior to actually writing the code itself.  Sounds a little strange and against the thought of the mainstream coding paradigm where the test itself is done after the code has been written prior to implementation. 

However, through TDD coding can actually be done quicker, meeting user requirements, and requiring less timely maintenance than in coding the old fashioned way.

As a coder would you rather spend more time debugging, refactoring, or being able to develop new code to meet yet another never-ending user requirement.  TDD enables the coder to spend less time babysitting the code because the tests are in place to provide a first line of security.

An excerpt from Wikipedia

Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.  Test-driven development requires developers to create automated unit tests that define code requirements before writing the code itself. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers often use testing frameworks, such as xUnit, to create and automatically run sets of test cases.

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left

Until next time…

como já diria Joel Spolsky… este blog já está fedendo a cupim (não, Joel não disse isso, na verdade do que se trata dele terminou nas reticências e tinha a ver com o titulo do post) mas tudo bem, esta é uma rapidinha que, se eu tivesse um numero consideravel de seguidores no twitter, seria um twitt… mas, como eu não gosto do twitter e nem quero que você me siga, vai pra cá mesmo.

Tudo que você faz, o faz como se você mesmo fosse usar? Pense nisso antes de construir a próxima linha de código lá no seu trabalho, esqueça seu chefe chato (não que o meu seja, caso o mesmo leia este post…) e codifique como se você mesmo fosse seu próprio usuário, como se você dependesse do seu próprio sistema para realizar seu trabalho.

Afinal de contas meu caro colega, os usuários gostariam tanto, mas tanto, que o que tu faz realmente funcionasse, que eles seriam capazes de te dar um beijo nas nadegas a cada dia de caixa fechado sem bug no sistema. E eu, sendo o cara que irá dar manutenção no seu código, adoraria tanto ver uma suite de testes unitários bem construidos quando o pegasse, que seria capaz de.. te pagar uma Polar bem gelada no boteco mais badalado da cidade baixa aqui de POA.

“Ah, mas eu já escrevo todo aquele código e testo tudo no main..  ainda tenho que escrever testes unitários pra ele?” Amigão, se tu quiser não precisa mais escrever este código todo.. escreva apenas os testes então. Ééé, isso mesmo. Esqueça aquela coisa toda logo de cara e vá direto aos seus @Test.. apenas coloque na cabeça: só entregue este código depois que os testes passarem! Se por acaso, tu ter que codificar um pouco para os testes passarem, beleza, tu faz classe a classe, mas espere, a classe não precisa existir para tu escreve-la pela primeira vez no seu teste… deixe o Eclipse chorar mesmo, só depois tu cria, ou melhor, rode a droga do teste sem a classe, para tu VER na tela que nada funciona sem a presença da maldita classe. É bem simples, não precisa ler um livro para começar.. são regrinhas básicas: da direita (seus testes) <simula erro> para a esquerda (implementação de uma pequena porção de código) <testa>.

“Mas quando eu sei que não preciso mais testar?” Quem disse que não precisa mais testar? Sempre que tu tocar aí tu vai testar, a unica diferença é que não precisará mais se preocupar com o que já está testado, pois se der algum tipo de erro, tu saberá exatamente onde consertar. Eu mesmo, sei quando não preciso mais testar quando o código que eu preciso para entregar a minha estória está pronto e é suficiente, pois de acordo com o TDD, se ele já está pronto, é porque existe um teste para ele!

Finalizando.. “eat your own dog food” .. estou ficando louco ou:

a propósito (falando em loucos), aproveitando a presença do Rod Johnson na TDC, nos diga Rod: o que faz a SpringSource, usar PHP no seu portal? http://www.springsource.com/index.php, Por quê não o nosso amigo SpringMVC?

E que calor infernal em Porto Alegre…

Test driven development is mystical to anyone that hasn’t done it from the ground-up. It’s almost like riding a bike; you really don’t know how easy it is and how much fun you can have with it until you get up and going. When the training wheels are off, it then becomes a brand new world full of possibilities.

I have been writing unit tests for years. Having come to the Java game later than most of my colleagues, I really like to make sure that everything I commit to my various development communities are well-tested and as clean as I can make them. Unit testing has allowed me to verify this in two different ways. First, it guarantees that what I’ve writting works, and more importantly, it makes me keep my code simple. Frankly, if I start writing a test and it becomes a dependency-driven, closely-coupled to the implementation monster, I can pretty much guarantee that the code is going to be the same. I’ll try to refactor this and use my tests in this manner as a guage for it’s quality.

So exactly HOW would I begin development by writing a test BEFORE I write any actual code, and WHY would I even want to?

We’ll address the “why” aspect first. “Old School” developers that I learned most of my skills from would create “fake” layers that the code that they were writing would have to talk to. A “fake layer” is defined as some type of data or code that simulates the functionality of an “expected” production-level deployment.

These “fake layers” would be similar to tests, but these guys wouldn’t write tests because they never did in the past (and some still don’t!). Testing just gives you a better framework for creating fake layers that you can create your code around.

HOW do you start with a test?

It’s actually quite simple. Let’s say you will be writing an application that talks to a database that has been created (you could even start without the database and just an ER diagram, but let’s keep it kinda simple). Looking at your requirements, you are probably going to implement CRUD operations against it. You start thinking about what the interface for the Data Access Object is going to look like. Hmmmm — Let’s see — CREATE, READ, UPDATE, DELETE. So your simple Interface has four methods.

Now start with a test. Create a class called MyDAOTest. MyDAOTest will test the Implementation Class for the interface’s methods. When we create a method in the test that tests well, we then create the interface method, then the move the test method, with proper modifications, into the a new MyDAOImpl class. It makes you create very smart tests that ensure you are “CRUD-ing” the data you expect. Coding in this way also creates the implementation to your interface at the simultaneously with the test. Finally, it makes you think about the interface and the implementation, and affects your overall design in a very positive light.

Now let’s take it further. You’ve created all the methods in your Impl class and your Interface methods can be extracted and the actual interface is now written and, for the time being, complete. Now let’s write a test that calls the Interface and implements a new Implementation Class through it. You can now see how clean your Interface is — how easy are your methods to use, how are things being cleaned up, and finally, how are exceptions being caught? Are you satisfied with the results so far? If so, proceed to the next layer!

The next layer may possibly involve a creating a Session Facade to allow for user interaction with the database (simple implementation, obviously). You can then create an Object model that translates the Database relationships into some type of presentation-level object gouping, and write tests to reflect this. It becomes very obvious what objects you need when you start writing a test that outputs the data that you want in a conditioned manner. Your first cut at it may look like horrible code! It may be some type of monolithic monster, but then you can see how things need to be split up. You keep splitting things up and writing tests around it, and sooner rather than later, you are suprisingly code-complete!

Do what works for you.

Even after all this I’m sure that some peoople are completely poo-pooing what I’m saying. That’s fine if it works for you. I’ve found that even if I begin by writing code to tests and continue writing tests and interfaces and all kinds of extra, “non-production” code, my productivity jumps dramatically as the project continues because I write less and less code as the project nears completion.

It’s about making everything solid. Using TDD, you’ll be writing one line of code to your previous ten, and when your “business guy” walks in and asks for a change, you’ll be going home at 5 instead of having your car languish in the parking lot after midnight. You’ll also have more confidence in the code that is checked in, and when things go wrong and the inevitable finger-pointing starts, you won’t be a pointee!

Just tried out one of the new features of JUnit 4.7 – @Rules. One I especially like allows you to perform further tests on thrown exceptions, as an extension to the @Test(expected=…) from earlier versions of JUnit. Putting back the check on thrown exceptions to the end of the unit test allows you to check for object end states and more details around the exception (message etc). However, if you’re also a fan of jMock then beware – the @RunWith(JMock.class) appears to prevent detection of the @Rules annotations, failing tests utilizing @Rules which pass without the @RunWith annotation. There seems to be little downside to running your tests without the @RunWith annotation, presumably less integration into JUnit 4 reporting.

I took another look at RSpec today. I tried to re-write the script using a test driven development method but am finding it harder to use than expected. I think I just have to shift my brain into programming TDD style. I really didn’t come up with any good code, I must have started over at least 10 times. I started with things like it “should accept a parameter –operation that takes either ‘add’ or ’sub’ as it’s value” Then I would read RSpec docs and try to test tha…needless to say it’s a good way to learn about RSpec albeit rather slow. Hopefully I can move my brain to this new style of thinking. It seemed so easy at first but once you try it, it’s actually kind of difficult to do.

Here is the list of requirements I’m going to be working off of.

• it “should accept two parameters, an operation that is either add or sub and a time value formatted at least with one digit. It should also accept two arguments, an in_file and na out_file”
• it “should add or subtract time based on the set operation”
• it “should modify the time by the amount passed in as a parameter of –time”
• it “should read times and all other lines from the first file”
• it “should write modified times and unmodified other lines to the second file”

IF you can get these tests to pass, then you’ve got yourself a working program and RSpec test to go with it as well as some documentation!

Until next time…

Sometimes it’s just nice to have everything you need in your apartment and you can just sit around and code :]

I decided today to try my hand at some unit testing using RSpec, as was suggested at the end of the challenge. I haven’t done much testing before so this seems like a good way to get started. The code I submitted includes a class definition as well as some imperative programming all in one. It would have been nice to separate that out, but this was supposed to be one script that works using the standard library. However, since this is beyond the challenge I’m going to test the class I’ve made, SubtitleTime. You can see it in the pastebin. It takes two parameters, a string in the format of HH:MM:SS,mmm and a ‘modifier’ that is either add or sub.

So starting off with RSpec first you have to ‘describe’ the class. Then you use a function named ‘it’ and write what the class should do. For example:

describe SubtitleTime do
    it "should be able to add another timestamp to itself" do
    end
end

Once that part of the code is written, then you just have to add some filler lines to actually test the code. This code above could be expanded to look like this:

describe SubtitleTime do
    it "should be able to add another timestamp to itself" do
        subtitletime.should add_time(another_timestamp)
    end
end # note: this has been crossed out as after reading more about RSpec, this just doesn't make sense.

Well after having written a few test cases and finally understanding what RSpec is all about, I feel like I should do this the right way and see what happens to my class if I built it using TDD (Test Driven Design). It initially seems very difficult to build up a test suite on an already existing piece of code. So let’s get started with some test cases.

First off we want the class to have a time that, before altered, is equal to the initial time. The code for that would look like this:

describe SubtitleTime do
    it "should have time equal to the initial time before the class is altered" do
        subtime = Subtitletime.new(:initial)
        subtitle.time.should == :initial
    end
done

Then When you run this test with the command <spec subtitletime_spec.rb> it will fail saying there is no class SubtitleTime. Simple. The idea behind TDD is that you make a test case, have it break, then fix it. An occasional (or after each iteration) step of refactoring your code should also be included in this process. So now I’ll make a class SubtitleTime

class SubtitleTime
end

This fixes the first error but we still get another error as the test is run. But that’s all I have time for right now, I was using an ibm guide to rspec. That should make things fairly clear. There is a lot to go over and a lot to do, but I’ll get back to this hopefully sooner rather than later and then finish up this challenge’s extras!

I attended a panel discussion sponsored by Rally Software this month. The panel was composed of individuals from different industries, each holding quite different roles in their organizations. They each contributed to a discussion of Agile and its benefits and challenges through the lens of their respective roles. This was probably what made the dialogue intriguing for me. The executive-level presentations made sense, and they focused on metrics and strategies for management approval, the buy-in and then follow-up phases, reporting on the velocity and productivity gains Agile can bring to product development.

However, the technically focused management reminded me of bad habits that are often overlooked in the rush to see rapid productivity improvements. I cannot present all the materials here without permission, but I will reiterate the basic message (and thank you Heather for this insight)…
Agile as a process is a collection of practices that works as a “collection”. Each practice is coupled with, and balanced by, the other practices. Sort of an ecosystem, were the inter-dependencies result in success or assured extinction for all. New practitioners, startup ventures, pilot programs and specific industries all tend to adopt Agile in a primordial way, by collecting the most relevant practices and adding them to the “soup”. Teams build an Agile “soup” based on need and how much change and training they can absorb quickly. A very common sense and practical way to get rolling with Agile. This is why training and coaching are so important to new adopters, it is often the missing key to success in these lean, budget cutting times.

Nonetheless, as organizations grow and the process matures, managers want to add to the maturity of their Agile practice by “cherrypicking” additional practices and adding them to their Agile “soup”. Here is where things can go awry. The practices and the disciplines are not intended to be mix and match. As stated in earlier posts, this is where “hybrid” approaches tend to evolve and teams try adding in waterfall practices and milestone gating steps to resolve where they are having issues. This is not wrong (but nor is it Agile). These modifications and “cherrypicking” of additional practices is where a clear understanding of Agile is required. For example: There is a growth in the number of teams and an explosive growth in the interdependent nature of the work being done, the group decides to add a “Scrum of Scrums” to have better team oversight. Here the group is adding a practice that fits into the Agile framework and upholds the ecosystem. Another example: A new team is added to work on platform services to be used by all the teams, this new team is technically strong and very dedicated to delivering on time to their co-dependent team mates. They breakdown all their user stories and pre-plan each in detail and discuss all the tasks and tests required. When they are finally certain they understand all the work, they commit to the stories and start the sprint. Unfortunately, this is waterfall estimation at a task level and not Agile. Even though the team’s intentions are good, they are operating as a rogue waterfall team compared to the other Agile teams by doing extensive task level estimation work prior to committing to stories. The other risk is that this team may be blocking the goal of “collective code ownership” as they focus and specialize.

Returning to some of the codependent practices, here is a short list of elements that work inter-dependently in an Agile ecosystem:

• TTD (test driven development)
• Pair programming
• Collective Code ownership
• Continuous Integration
• Simple Design
• Refactoring
• Automated Acceptance Testing
• Customer Involvement
• Adaptive Planning
• Sustainable Pace
• Small Iterations and Releases
• Continuous Feedback
• QA Involvement
• Empowered Teams
• Eliminating Waste
• “Done Done” Stories
• Estimate-able Stories
• Iteration Velocity
• Inspect and Adapt (Retrospectives)
• Whole Teams

When teams are inspecting and adapting (often through retrospectives) then helpful practices may be added or may evolve. However the panelists were clear in this message,  when “cherrypicking” to grow process improvements it is important to recognize how the ecosystem works as a whole and select component practices wisely so as not to disrupt the entire system. Remember to focus on complementing the practices the team has successfully adopted and reflect of the health of the ecosystem.

Disclaimer: I will NOT disclose what the answers are to these problems.  The intent is that the testing is just as important, and in most cases, more than the answer.  If you want to know what the answer is without solving the problem, a simple google search will tell you what it is.

Background:

• If you are not familiar with the series, please read this.
• This is Java driven as well as JUnit 4.
• You are familiar with TDD tenants.

References:

• All references to this series can be found in the parent blog.

Problem:

“A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 × 99.

Find the largest palindrome made from the product of two 3-digit numbers.”

Difficulty: Easy

The Test File:

• Please download it here.

Explanation:

A brute force approach would be to go from 10,000 to 998,001 and evaluating each number for the two criterea:

• Is this number a Palindrome?
• Is this number a product of two three digit numbers?

Not being a mathematician, I kind of liked a brute force idea, but I tweaked it a bit.  Instead of an incremental approach from min to max, I decided to use a decremental approach.  I suspected that the answer should be in the 900,000’s.  I only have to traverse through, at most, 100,000 integers.

For determining the divisibility, I was also going to take a brute force approach as well, but I was going to make an assumption.  That is, I’m going to guess that both products will be between 800-999.  So the determination will be a decremental loop starting from 999.  If the palindrome is evenly divisible by that number, I would divide the palindrome with that number, and check if the product is less than 1000.  So it goes like this:

• Start from 998,001 and decrement by one in a loop.
• Is the number a palindrome?
• If so, is it divisible by a number in a decremental range starting from 999, and ending in 800.
• If so, is the product of the palindrome and that number less than 1000?
• Good.  Print the number, or print the number and exit.

The hardest thing about this problem then was then evaluating whether or not a given number is a palindrome or not.  I know what a palindrome is, but I never implemented an algorithm that evaluated a palindrome.  With strings, it’s slightly easier because you can easily compare first and last characters in Java and then strip them.  You have charAt at your disposal, substring and many implementations of strip (first and last chars).

With numbers how do you do that?  I didn’t know, so I had to write it out on paper.  After that, it was fairly straight forward.  I had to write an algorithm that compared the first and last digits of the number using modulo based on ten and divisors based on 10.  Then I had to write an extractor that stripped out the left and right most digits.

Stop if the stripped digit is either single or double digits.  If it gets down to single digits, the number is a palindrome.  i.e.: 151 is a palindrome because the first and last digits are equal and the remainder is 5.  This works for all three digit (or odd) digit numbers.

Stop if the stripped remainder is two digits.  If the number is a palindrome (22, 33, etc) return true.  Else return false.

Implementation Details:

Methods shouldTestGetLeftMostNumber, and shouldTestGetRightMostNumber were my first two test methods.  It was easy to implement (10 based divisors retrieved left most numbers, modulo retrieved right most numbers).  I started with one test first, for example:

• Given the number 5, I expect that left most number is 5.  Assert that 5 is expected against the actual, 5.

Then the tests followed…

• Given the number 61, I expect that the left most number is 6.  Assert that expected and actual are equal.
• You can do tests for any random 3, 4, 5 and 6 digit numbers.

Getting the right most number was similar and just as trivial.  Example:

• Given a number 462, I expect that the right most number is 2.  Assert!
• I didn’t do negative cases because I used random numbers.

So a palindrome checker is fun to implement.

• Are the two numbers  on the ends equal?  If not, stop and return false;
• If so return the center.
• Stop and return true if the remainder is single digit.
• Stop and return false if the remainder is double digit but not a palindrome.
• Stop and return true if the remainder is double digit and is a palindrome (22, 33,  44, etc).

That’s it!!!  Now, how you implement your methods are totally up to you.  You can use recursion for the palindrome checker, but I didn’t.  I used iterative approaches for speed (although, unlike the Fibonacci problem, recursion shouldn’t pose to much of a performance hit).

Divisibility by three digits is easy as well.  It’s trivial so I need not write out the implementation.  Just guess that the range is between 999-800, decremented.

I always seem to struggle to find examples of how to use MethodOptions in Rhino Mocks, so here is some code.

Assume you have the following dependency:

public interface IDependency {
   void SomeMethod(int number);
   void SomeMethod(ComplexType complexType);
}

public class ComplexType {
   public string Name { get; set; }
}

And your system under test calls this dependency like this:

public class SystemUnderTest {
   private readonly IDependency dependency;
   public SystemUnderTest(IDependency dependency) {
      this.dependency = dependency;
   }

   public void DoSomething() {
       dependency.SomeMethod(9);
       dependency.SomeMethod(3);
   }

   public void DoSomethingElse() {
       dependency.SomeMethod(new ComplexType{Name = "London"});
   }
}

You can use MethodOptions to check that the dependency was called correctly.

First, let’s check that SomeMethod was called twice with integers greater than 1:

[Test]
public void EnsureDependencyCalledTwiceWithAnIntegerGreaterThanOne() {
  var dependency = MockRepository.GenerateStub<IDependency>();
  var systemUnderTest = new SystemUnderTest(dependency);
  systemUnderTest.DoSomething();

  dependency.AssertWasCalled(x => x.SomeMethod(0),
                                                 options =>
                                                 {
                                                     options.Repeat.Twice();
                                                     options.Constraints(Is.GreaterThan(1));
                                                     options.Message("SomeMethod should have been called twice with integers greater than 1");
                                                 });
}

Next, let’s check that the correct ComplexType was sent to SomeMethod

[Test]
public void EnsureDependencyCalledWithCorrectComplexType() {
  var dependency = MockRepository.GenerateStub<IDependency>();

  var systemUnderTest = new SystemUnderTest(dependency);
  systemUnderTest.DoSomethingElse();

  Func<ComplexType, bool> checkArgs = arg => arg.Name == "London";
  //The above line can be written with an anonymous method instead:
  //Func<ComplexType, bool> checkArgs = delegate(ComplexType arg) { return arg.Name == "London"; };

  dependency.AssertWasCalled(x => x.SomeMethod(new ComplexType()),
                                                        options => {
                                                           options.Callback(checkArgs);
                                                           options.Message("Name sent was not London");
                                                        });
}

Test driven development is not an easy subject. And to be honest, I’ve not been convinced of it’s usefullness when first reading about it, witnessing this post. What I do believe firmelly is the usefulness of unit testing. But I have found that overall resistance to unit testing is rather big mostly because if not done well it turns out to be rather timeconsuming.

Now, let me start by saying I’m not an expert on the subject. I’ve tried applying it to some projects with some success and wanted to use it extensively in the next major release of my Offline Maps project. So I did some research to find where I could improve and my first subject was mock objects.

It turned that mocks are only a part of the complete picture.

Ok mocks, but what about stubs, dummies, fakes, etc…

There is a lot of lingo surrounding unit testing. Before we get any deeper on mock objects lets clearly define what they are and more importandly, what they are not and what differentiates them from stubs, fakes, etc…

Stubs

According to Jeremy Miller, the difference between mocks and stubs is mostly in the sort of testing you’re performing:

The real difference between a mock and a stub is in the style of unit testing, i.e. state-based testing versus interaction testing. A stub is a class that is hard-coded to return data from its methods and properties. You use stubs inside unit tests when you’re testing that a class or method derives the expected output for a known input.

Gerard Meszaros provides a bit more detail:

In many circumstances, the environment or context in which the system under test (SUT) operates very much influences the behavior of the SUT. To get good enough control over the indirect inputs of the SUT, we may have to replace some of the context with something we can control, a Test Stub.

So, you use stubs if you want to provide data to your system under test and the outcome of your system under test is dependend on the content of that data. A good example would be an object which has as input the current date and for example calculates yesterday. If you where to use the effective current date, then you could never write a test because each different day you execute the test would use a different current day, thus calculate a different yesterday and thus the value against which you want to check would change every day. If you however create a stub which provides a current day that you can set fixed, then you can reproduce the result whenever you want:

An example:

The code we want to test is the following:

public ITodayProvider TodayProvider { get; set; }
public DateTime Yesterday
{
	get { return TodayProvider.Today.AddDays(-1); }
}

The implementation of ITodayProvider used in the application uses the system date:

public DateTime Today
{
	get { return DateTime.Today; }
}

The implementation of ITodayProvider used in the test however allows to set the date that will be returned:

public DateTime Today
{
	get;
	set;
}

The test with the ITodayProvider using the system date does not produce repeatable results:

[Test]
public void WithoutStubTest()
{
	CalculateYesterday yesterdayCalculator = new CalculateYesterday();
	yesterdayCalculator.TodayProvider = new TodayProvider();

	// Unless you execute this test exactly on 1st september 2009, this test will fail
	Assert.AreEqual(new DateTime(2009, 8, 31), yesterdayCalculator.Yesterday);
}

The test with the ITodayProvider which can be set does allow to produce repeatable results:

[Test]
public void WithStubTest()
{
	CalculateYesterday yesterdayCalculator = new CalculateYesterday();
	TodayProviderStub stub = new TodayProviderStub();
	stub.Today = new DateTime(2009, 9, 1);
	yesterdayCalculator.TodayProvider = stub;

	// This test will always succeed, that is if you implementerd the yesterday calculation correctly.
	// It is however completely independent of the day the test is executed
	Assert.AreEqual(new DateTime(2009, 8, 31), yesterdayCalculator.Yesterday);
}

Fakes

Where a stub actually influences the system undertest, a fake only “fakes” an object in the system under test. Again according to Gerard Meszaros:

The SUT often depend on other components or systems. The interactions with these other components may be necessary but the side-effects of these interactions as implemented by the real depended-on component (DOC), may be unnecessary or even detrimental. A Fake Object is a much simpler and lighter weight implementation of the functionality provided by the DOC without the side effects we choose to do without.

Matin Fowler in his post on different kinds of test doubles states the following:

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example) So whereas stubs don’t have any working functionality, fakes have. They just take some shortcuts. Stubs are typically hardcoded to return some value.

As an example, suppose your object uses a webservice for retrieving some values, you may not be interested in setting up a connection to the webservice, provide a connection string, etc… because the actual webservice used is unimportant to your system under test. You also don’t want everyone executing your tests to be dependend on the availability of that webservice or detrimental behaviour like unavailable connections, timeouts and all that sort of stuff specific to webservices to mess up your test. In this case you could use a fake in webservice which provides the same functionality but is much easier in setup and which doesn’t exhibit the unwanted behaviour of unavailable connections and timeouts.

The code we want to test is the following:

public ITodayProvider TodayProvider { get; set; }
public IDayRangeCalculatorService DayRangeService { get; set; }
public DateTime YesterdayUsingDayRangeService
{
	get
	{
		IDayRangeCalculator dayRangeCalculator = DayRangeService.ConnectToService();
		int daysBetween = dayRangeCalculator.DaysBetweenTodayAndYesterday();

		return TodayProvider.Today.AddDays(daysBetween);
	}
}

A fake implementation of the service allows to get away of all problems relating to connecting to and using of webservices:

class DayRangeCalculatorServiceFake : IDayRangeCalculatorService
{
	#region IDayRangeCalculatorService Members

	public IDayRangeCalculator ConnectToService()
	{
		return new DayRangeCalculatorFake();
	}

	#endregion
}

class DayRangeCalculatorFake : IDayRangeCalculator
{
	#region IDayRangeCalculator Members

	public int DaysBetweenTodayAndYesterday()
	{
		return -1;
	}

	#endregion
}

By using the fake in the test we know our test will not fail because of problems related to the webservice. So if our test fails, then we know it’s because our algoritme failed:

[Test]
public void WithDaysBetweenServiceFakeTest()
{
	CalculateYesterday yesterdayCalculator = new CalculateYesterday();
	TodayProviderStub stub = new TodayProviderStub();
	stub.Today = new DateTime(2009, 9, 1);
	yesterdayCalculator.TodayProvider = stub;

	yesterdayCalculator.DayRangeService = new DayRangeCalculatorServiceFake();

	// In this test we are only interested if the method returns the correct yesterday
	//  and not if the logging was done correctly
	Assert.AreEqual(new DateTime(2009, 8, 31), yesterdayCalculator.YesterdayWithLogging(new LoggingDummy()));
}

Dummies

Dummies have no influence at all on the tests. They are just used to provide values for method parameters, etc…

Fowler:

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Thus, you use a dummy if you test requires an object which thus not have any influence on the outcome of your test. An example could be a method called in your test which has some specific outcome you want to check but for example also take a logging object as a parameter. Remember we are unit testing and each test checks on some aspect of the object. So we want to check the specific outcome of calling the method but in this test we are not at all interested in the logging of the method. Then we provide a dummy logging object which actually thus nothing but allows us to call the method and check the expected outcome.

The code we want to test is the following:

public ITodayProvider TodayProvider { get; set; }

public DateTime YesterdayWithLogging(ILogging logging)
{
	logging.LogMessage("Executing YesterdayWithLogging");
	return TodayProvider.Today.AddDays(-1);
}

In our test we don’t care about logging. So we provide a dummy logging class which does nothing:

class LoggingDummy:  ILogging
{
	#region ILogging Members

	public void LogMessage(string message)
	{
	}

	#endregion
}

In our test we don’t have to worry about the logging

[Test]
public void WithLoggingDummyTest()
{
	CalculateYesterday yesterdayCalculator = new CalculateYesterday();
	TodayProviderStub stub = new TodayProviderStub();
	stub.Today = new DateTime(2009, 9, 1);
	yesterdayCalculator.TodayProvider = stub;

	// In this test we are only interested if the method returns the correct yesterday
	//  and not if the logging was done correctly
	Assert.AreEqual(new DateTime(2009, 8, 31), yesterdayCalculator.YesterdayWithLogging(new LoggingDummy()));
}

Now, if all this is a bit overwhelming, don’t be concerned. Your test doubles will mostly be a mix of the above, or their focus or purpose will shift as shown by Daniel Cazzulino in his postMocks, Stubs and Fakes: it’s a continuum .

Mock objects, what problems to they solve ?

In many posts about the type of test doubles there is also the difference between test spies and mocks. From what I could find on them the difference is not that clear to me. So I will treat them as being the same. Of course, if you can explain the difference in a clear way, you’re welcome, or if you know a reference let me know.

About behaviour

We all know it but lets state it once more explicitely:
Objects are instances of classes which exhibit both state and behaviour.

Anyone studying UML will agree that both the class diagram and the sequence diagram are needed to document the interactions of systems. Where the class diagram shows what properties the classes in the system have, the sequence diagram shows what the important method calls made by the objects are. So you could say that the class diagram documents the state of a system (not entirely thru) and the sequence diagram documents the behaviour of the system. And as you need both the class diagram and the sequence diagram you need both state testing and behaviour testing.

When to use mock objects

The main difference with traditional testing is that where traditional testing allows a more state-based approach of testing, mock objects provide a behaviour style of testing. We all know the traditional style of unit testing using frameworks like NUnit, MbUnit and there assert-style testing:

1. Setup your test
2. Execute some action
3. Assert that the properties of the object under test are what you expect

We assert that the state the object under test is in, is what we expect. To check this state, we check the values of the object’s properties.

Behaviour style testing on the other hand verifies the dynamic behaviour of the object under test. Remember that we are using mock objects to represent companion objects “on the edges of the object under test”. That is, objects used by our object under test. Now, sometimes we will want to know if our object under test calls a certain method with certain arguments of the companion object. The post Using Mock Objects Effectively provides a great example:

On closer inspection, it becomes clear that the application is not actually logging anything. Log4J is responsible for doing that. What the application is truly doing is sending a signal (a request) to log4j to log a message. That distinction is *very* important. The appropriate test then is simply to verify that the application is sending the correct signal to the service provider under the right conditions.

We now get following test sequence:

1. Setup your test
2. Execute some action
3. Assert that the required methods have been executed with the correct parameters and in the correct sequence

We assert that the object under test executed the behaviour we expect. To check this behaviour, we check the methods it called and the arguments it provided to those methods.

So, using mock objects for behavioural testing can co-exist with the more traditional style of sate based testing.

Martin Fowler, him again, warns for some caveats when using mock style testing in his article Mocks Aren’t Stubs:

When you write a mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers…
Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.

An example

The code we want to test is the following:

public ITodayProvider TodayProvider { get; set; }

public DateTime YesterdayWithLogging(ILogging logging)
{
	logging.LogMessage("Executing YesterdayWithLogging");
	return TodayProvider.Today.AddDays(-1);
}

In our test we don’t care about the exact output of the logging but we do care if the logging is called and if it is called with the correct arguments. So we want to record the methodcall and the arguments with which it got called:

class LoggingMock:  ILogging
{
	public int NumberOfMethodCalls { get; private set; }
	public List<String> MethodCallArguments { get; private set; }

	#region ILogging Members

	public void LogMessage(string message)
	{
		NumberOfMethodCalls++;
		if (MethodCallArguments == null)
		{
			MethodCallArguments = new List<string>();
		}

		MethodCallArguments.Add(message);
	}

	#endregion
}

By recording the calls we can check in our test if the method got called and if the provided arguments where correct:

[Test]
public void WithLoggingMockTest()
{
	CalculateYesterday yesterdayCalculator = new CalculateYesterday();
	TodayProviderStub stub = new TodayProviderStub();
	stub.Today = new DateTime(2009, 9, 1);
	yesterdayCalculator.TodayProvider = stub;
	LoggingMock loggingMock = new LoggingMock();

	// In this test we want to see if the logging is called correctly
	DateTime yesterday = yesterdayCalculator.YesterdayWithLogging(loggingMock);

	Assert.AreEqual(1, loggingMock.NumberOfMethodCalls);
	Assert.AreEqual("Executing YesterdayWithLogging", loggingMock.MethodCallArguments[0]);
}

Sample Code

The Code

Links

Mock Objects and Stubs: The Bottle Brush of TDD
Why and When to Use Mock Objects
Best and Worst Practices for Mock Objects
xUnit Patterns
Using Mock Objects Effectively
MF Bliki: TestDouble
Mocks Aren’t Stubs
Mock object

I just finished doing every exercise of Agile Java: Crafting Code with Test-Driven Development by Jeff Langr.

You can find the solutions to all the exercises in my Git Hub repository.

Install git (version control system) and use the following comand:
git clone git://github.com/cyberroadie/spikes.git
to check out the code.

The exercises are not indexed but I added tags (Lessonxx) for every chapter I finished. There are 3 main parts: The chess game, the exercises you can find at the end of every chapter and some exercises I did whilst reading the chapters.

Although Jeff did use JUnit 3 and Ant in the book, I used Maven and JUnit 4 instead.

Please feel free to use this code and I’m happy to receive any updates/patches/improvements

Happy Coding

Olivier

There seems to be several methods out there, based on elevating warnings to errors using warnings.simplefilter. Here’s another method, based on recording warnings in a variable, and checking that the last one is a MySQLdb.Warning. Hopefully to be integrated in INSPIRE.

import MySQLdb
import unittest
import warnings
[...]
class TestTagInsert(unittest.TestCase):
    def test_too_long_tags(self):
        with warnings.catch_warnings(record=True) as warn:
            [Run SQL statement]
            self.assert_(len(warn) == 1) # Ensures that the next statement won't break the testing
            self.assertEqual(
                MySQLdb.Warning,
                warn[-1].category
                )
            #If you also want to check the text of the warning:
            self.assert_(
                'truncated' in str(warn[-1].message))

Hoy comenzaré el día escribiendo un post después de casi dos meses lejos del blog, ha sido un tiempo largo pero ha sido aprovechado para aprender nuevas tecnologías e historias que compartir por aquí.

El tema de hoy será como escribir pruebas unitarias usando mock objects, pero, ¿qué son los mock objects? Yo los definiría como objetos programables para que se comporten de una manera determinada en runtime. ¿Y para qué puede servirnos esto al hacer pruebas unitarias? Nos servirá para probar las clases aisladas de sus dependencias, así, si una de las clases de las que nuestra clase depende falla, entonces este error no afectará la prueba unitaria de nuestra clase y deberemos identificar y solucionar ese problema en la otra clase (que debería tener escritas algunas pruebas unitarias).

Veamos un ejemplo en el que las depedencias pueden fallar.

La clase que queremos probar es ManejoDeUsuariosImpl, una implementación de la interface ManejoDeUsuarios, ésta clase se compone de instancias de LDAPAccesibleImpl, esto significa que si algo falla en LDAPAccesibleImpl nuestra clase también fallará probablemente y al hacer pruebas unitarias lo que queremos es someter a prueba exclusivamente el comportamiento de una clase independientemente del correcto funcionamiento de sus dependencias. Para darnos una mejor idea… ¿Qué podría fallar en LDAPAccesibleImpl? Hmm creo que todo, podría fallar la conexión de red al servidor LDAP, podría suceder que hayan eliminado al usuario que pensabamos usar para nuestras pruebas unitarias, etc.

Bueno, veamos un ejemplo de prueba unitaria para nuestra clase ManejoDeUsuariosImpl que es la implementación de ManejoDeUsuarios.

ManejoDeUsuarioImplTest.java

package com.imageneureka;

import org.junit.Test;

import static org.easymock.EasyMock.*;

public class ManejoDeUsuariosImplTest {

 private static final String USUARIO_ACTIVO = "active";
 private static final String USUARIO_NO_EXISTENTE = "inactive";

 @Test
 public void hacerAlgoConUnUsuarioActivoTestHappyPath()
 throws Exception {
 // primer paso: creamos el mock, usando el metodo
 //estatico org.easymock.EasyMock.createMock
 LDAPAccesible foo = createMock(LDAPAccesible.class);
 // segundo paso: establecemos el comportamiento
 //, parametros -> respuesta
 expect(foo.esUnUsuarioActivo(USUARIO_ACTIVO)).
 andReturn(Boolean.TRUE).anyTimes();
 // invocamos replay sobre el mock
 replay(foo);
 ManejoDeUsuariosImpl bar = new ManejoDeUsuariosImpl();
 // necesitamos esta linea para establecer la instancia
 //de LDAPAccesible que usara
 // nuestra clase a probar, en este caso el mock
 bar.setMyLDAPAccesibleImpl(foo);
 bar.hacerAlgoConUnUsuarioActivo(USUARIO_ACTIVO);
 // invocamos verify sobre el mock
 verify(foo);
 }

 @Test(expected=IllegalArgumentException.class)
 public void hacerAlgoConUnUsuarioActivoTestLLamadaIncorrecta()
 throws Exception {
 // primer paso: creamos el mock, usando el metodo estatico
 //.easymock.EasyMock.createMock
 LDAPAccesible foo = createMock(LDAPAccesible.class);
 // segundo paso: establecemos el comportamiento,
 //parametros -> respuesta
 expect(foo.esUnUsuarioActivo(USUARIO_NO_EXISTENTE)).
 andReturn(Boolean.FALSE).anyTimes();
 // invocamos replay sobre el mock
 replay(foo);
 ManejoDeUsuariosImpl bar = new ManejoDeUsuariosImpl();
 // necesitamos esta linea para establecer la instancia
 //de LDAPAccesible que usara
 // nuestra clase a probar, en este caso el mock
 bar.setMyLDAPAccesibleImpl(foo);
 bar.hacerAlgoConUnUsuarioActivo(USUARIO_NO_EXISTENTE);
 // invocamos verify sobre el mock
 verify(foo);
 }
}

Antes de que revisemos el ejemplo les sugiero bajarse el ejemplo completo para que puedan ver la dependencia entre las clases de implementacion y asi puedan darse una idea mas clara de qué es lo que pretende testear esta prueba unitaria.

http://www.2shared.com/file/8369937/d643442b/easyMockTest.html

En el archivo que bajarán encontrarán una carpeta con un archivo pom.xml, éste es el project object model de maven, para los que no conocen maven, es un manejador de dependencias y proyectos muy útil, con él solamente necesitan el pom.xml y las dependencias (jars) se bajan de internet automáticamente, además ya se está convirtiendo en el estándar para gestionar proyectos, por lo tanto: http://www.chuidiang.com/java/herramientas/maven.php además tiene muy buena integración con los IDEs que conozco, a saber Netbeans y Eclipse, en Netbeans tan solo tiene que ir a instalar plugins seleccionar el plugin para maven y ya esta, listo para usar.

Regresando a los nuestro, en esta prueba unitaria hay dos métodos de prueba, uno de ellos (hacerAlgoConUnUsuarioActivoTestHappyPath() ) prueba la clase bajo circuntancias favorables (usuario válido) y el otro (hacerAlgoConUnUsuarioActivoTestLLamadaIncorrecta()) prueba la llamada al método ManejoDeUsuariosImpl.hacerAlgoConUnUsuarioActivo() con un usuario incorrecto, circunstancia bajo la cual éste metodo debería responder con una excepción IllegalArgumentException y el proceso de emulación del comportamiento de la dependencia de la clase a testear se detalla como comentarios en el ejemplo.

Por último, cabe mencionar que easyMock no es el único framework para crear mock objects, también existe JMock, el cual implementa ésta funcionalidad aunque con un estilo DSL

It was early October of last year that we took the first steps towards adopting Scrum and undertaking the challenge of becoming more agile.  I figure this is a good time to review the year, the progress we’ve made, and the challenges we still have to overcome.

Original intentions

My original intentions with Scrum were to adopt a methodology that forced issues to the surface and gave us some flexibility in dealing with them.  Specifically, I felt: (1) my staff weren’t working together as well as they could, (2) we had serious quality issues with our applications, and (3) projects lacked visibility with the business.  I think that these were largely symptoms of underlying issues, and I hoped Scrum would allow us to bring those issues to the surface and deal with them.  So …

How did it work out?

Are my staff working better together?

Definitely.  There is a greater appreciation for each others’ roles.  We’ve largely eliminated the perspective that work can be thrown ‘over the wall’ (i.e. requirements over to development over to QA) with no interest in how others do their job.  There is a greater focus on the team and accomplishing something together.  And no one works in isolation with no understanding of what the person next to him or her is doing.

But we’re not quite there yet.  From my perspective we’ve come maybe 50% of how far I’d like use to go.  I’d like to see more critical thinking and discussion, and still more of a focus on the team.  I’d also like to see more thought going into and a stronger commitment to the sprint goals.  But there is no doubt in my mind that the Scrum framework can facilitate improvements in team work, and with my staff I think it will continue to do so.

Has quality improved?

We get some positive marks here, as well. Code coverage and documentation is probably five or ten times what it is in our legacy, pre-Scrum systems.  Regression bugs (i.e. those that crop up outside the execution of a story) are rare — maybe one or two a month.  As we are about to put the first piece of the system into production, I have great confidence that it should be essentially bug free.

But we still need our test coverage to be higher, and we need the quality of our tests to improve.  The team is still weak on Test Driven Development (TDD).  While we are making improvements, our focus on quality must continue to grow.  Again … we’ve come maybe 50% of how far we should go.

Has visibility increased?

In this area we’ve made incredible progress.  The quantification of user stories (we estimate using t-shirt sizes but I convert them to numbers) and the use of Version1 to manage our backlog have provided the project team and leadership with an unprecedented view in the project, our progress, and where we have to go.  In addition, Scrum has given us the tools to work more closely with the business, with stakeholders (not just the product owner) joining us for planning meetings and stand-ups.  I think their perspective on the work we do has changed … and just maybe become a little more sympathetic to the challenges of software development.

My Lessons Learned

Changing peoples’ perspectives is hard

You can never underestimate how hard it is for people to change their perspectives.  This has been one of my biggest challenges — getting my staff to see their jobs and our systems (products) from a different perspective.  My perspective on their roles has certainly changed: it’s clear to me know how important it is to have staff who aren’t just coders, who can see the big picture, who have good judgment, and who take it upon themselves to learn continuously (and not just about the latest technology).

I have definitely seen a change in all of my staff, but I have to admit I’d like to see more.

Training is critical to make a change like this

This is an obvious one, but I’ve learned it nonetheless.  Unfortunately we undertook a change towards Scrum just as the financial crisis hit, and as a result I had very little resources to train my staff.  Specifically I would have got them training in Scrum, and at least a class on test-driven development.  I also would have liked to have money to send them to conferences (specifically the annual Agile Vancouver event).  If I were to undertake this again at a different company, a lack of sufficient training funds would be a non-starter.

Get your systems in place first

By systems I mean proper development and test environments, build servers, et cetera.   It’s been a year and we’re still building out some of the infrastructure we need to be really agile (like a proper user acceptance testing environment).  I’ve read discussions of the value of a ’sprint zero’, which is used to set up all the infrastructure.  For us, we could have taken use a sprint zero through two or three to get it all set up.  It has impeded us at various levels since day one.  (Although, admittedly, we didn’t know everything we wanted or needed when we started, and some of his has been dictated by how the project has developed.)

Managing expectations is critical

Typically I’m pretty good at this, but there’s always room for improvement.  I was the one who sold Scrum internally, and in so doing established certain expectations with my bosses concerning what we could accomplish.  While I’m sure they see the value, I should have spent more time educating them on what we were doing and what they could expect from it.  I should have managed expectations better — but I was walking the fine line of selling the change enough that they’d buy in, but not so much that they’d think this would be a cure-all.

What’s next?

I have a few goals for the next six-to-twelve months.  As the team matures and our processes continue to stabilize, this will open up opportunities for additional improvements in how we work.

A greater focus on quality

From day one I’ve told the team that quality is non-negotiable.  That said, if everyone isn’t on the same page as to what quality means, it becomes negotiable anyway (we did define it, but there’s always room for interpretation).  We have recently improved the metrics we use and will take more proactive action with these metrics in hand to increase system quality.  This will involve some more learning within the team, and definitely some greater discipline.

Lean development

I recently read “Implementing Lean Software Development” by  Mary and Tom Poppendieck and it was awesome.  I had looked into lean concepts before, but it didn’t really seem to fit where we were as a development group (in other words I don’t think we weren’t ready for these ideas).  With a year of Scrum under our belts, now is the time to start maturing and getting a better understanding of some of the valuable ideas and practices lean offers.

Scrumban

This is related to lean development, but it involves more process changes to how we approach our work.  I see the value of continuous flow, but I don’t think the team or the company is ready to go there.  In six months, maybe … .  I definitely see this as a natural progression from where we are today.

Stepping Away

From day one I’ve acted as the ScrumMaster.  As the department director I’ve known this goes against best practices — managers shouldn’t be ScrumMasters.  Given our company culture, as well as resources we had at hand, I chose to take on this job anyway.  I think I have been reasonable successful, although I have plenty of examples of where my position has caused problems.  I will be stepping away somewhat, letting another team member take on many of the responsibilities.  I still plan to be involved from more of a coaching perspective — I probably still have the greatest technical knowledge of Scrum — but I won’t be as involved on a day-to-day basis.

And that’s all …

The past year my perspective on software development, team work, and project management has changed dramatically.  Scrum is good.