Archive

Archive for the ‘Testing’ Category

We All Live In An Uncle Bob Dialog

May 31st, 2010

Robert C. Martin (affectionately known as “Uncle Bob” in the development community) has a number of great books demonstrating the benefits of OOD/OOP and good design principles. Those acquainted with his books will also be familiar with his generous use of conversation dialogs between developers.

A sample excerpt:

RCM: “Will you help me write a little application that calculated bowling scores?”
RSK: “… Sure, Bob, I’d be glad to help. … I used to be a pretty good bowler … “
RCM: “Let’s begin with scoring a single game …”
RSK: “OK, we’re going to need some test data. Let me sketch out a little picture of a scorecard …”
RSK: “Shall we start at the end of the dependency chain and work backward? …”
- A Programming Episode from Agile Principles, Patterns, and Practices

This dialog continues for some 40+ pages as we’re walked through a paired programming session demonstrating test driven development and refactoring techniques. Admittedly, while reading these dialogs, I initially thought they were a bit over-the-top (campy), but as I actively listen to the communication happening within my team I realize that these dialogs are happening all around me.

An excerpt from this past week:

Me: “Will you help me write a stored procedure to retrieve the customer’s cart items count and default lightbox items count?”
Dev: “Sure, Adam, I’d be glad to help.”
Me: “Cool! This will be more efficient than aggregating the data from multiple repositories …”

Pull yourself in, that’s right, a little closer to the campfire, now sing it with me, “We all live in a yellow submarine… errr… an Uncle Bob dialog, an Uncle Bob dialog.” :)

Author: Adam Kahtava Categories: Musings, Software, Testing Tags:

More Reasons For Testing: Prevent The Morning-After Syndrome

March 11th, 2010

Testing (Test Driven Design, Unit Testing, Mocking) is a part of developer popular culture – most developers understand that by writing the tests first we’re forced to focus on the important details as we build software, that by writing tests we prove that our software works as we build it, and that by running our test suite against our changes we gain assurance that our code still works, but did you know that testing is also a cure for the ‘morning-after syndrome’?

The ‘morning-after syndrome’ as described by Uncle Bob (Robert C. Martin):

Have you ever worked all day, gotten some stuff working, and then gone home, only to arrive the next morning to find that your stuff no longer works? Why doesn’t it work? Because somebody stayed later than you and changed something you depended on! I call this ‘the morning-after syndrome’. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Bob makes the point that by writing tests we make our code more stable and brittle to change, which prevents our coworkers from making casual breaking changes. Sure-sure, brittle tests are frustrating when refactoring, but at the same time these brittle tests accentuate the importance that the code under test should not be modified. Core components that your system depends on should be stable and brittle.

Bob continues:

Many factors make a software component difficult to change: its size, complexity, clarity, and so on. But we are going to ignore all those factors and focus on something different. One sure way to make a software component difficult to change is to make lots of other software components [like tests] depend on it. A component with lots of incoming dependencies is very stable, because it requires a great deal of work to reconcile any changes with all the dependent components. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Author: Adam Kahtava Categories: Book, Quality Assurance, Testing Tags:

Memcached On PowerShell

March 9th, 2010

Memcached has been around for a while, but it's still pretty neat.

Experiencing a bottleneck with your Object Relational Mappers, Services, Middleware, Database, or whatever? Then Memcached it!

Memcached was intially developed for LiveJournal by Danga Interactive in 2003, and is used by many large sites (YouTube, Amazon, Twitter, to name a few). Today, you can find a Memcached library for all your favourite languages (here's the list).

Now; cache testing is tough period, and testing Memcached (which is accessed through a telnet client) is even more difficult - it's fair to mention that there are a large number of wrappers for Memcached outside the .NET world, but I couldn't find one for that met my needs.

Introducing Memcached on Powershell

Sample usage and output

Loading the script (source can be found here)

CODE:
  1. PS C:\> .\memcached-on-powershell.ps1

Checking Memcached stats on an empty instance

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  0
  3. No slabs found

Checking Memcached stats after items have been added to the cache

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  3
  3. Stats for Slab:  1
  4.          Key: 'resume-service:resume:adam-kahtava'
  5.          Key: 'open-source-service:github:adamdotcom'
  6.          Key: 'open-source-service:googlecode:adam.kahtava.com'

Clearing all Memcached items

CODE:
  1. PS C:\> clear-memcached-items 127.0.0.1 11211
  2. Total items in cache:  0

Checking Memcached stats on a cleared instance

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  0
  3. Stats for Slab:  1
  4.          Empty

If your test obsessed then you might be interested in the Memcached tests.

As always feel free to contribute, view, or download the source here.

Author: Adam Kahtava Categories: .NET, PowerShell, Testing Tags:

Behaviour Driven Development Frameworks are for Geeks and Crackpots

June 24th, 2009

Behaviour Driven Development (BDD) generally makes use of Mocks, Unit Tests, or specialized BDD Specification Frameworks like RSpec, MSpec, NSpecJBehave, NBehave. View the list of other BDD frameworks here and read more about BDD here: A New Look at Test Driven Development.

Now, I've been finding Behaviour Driven Development fascinating in a geeky kind of way (kind of like functional programming languages, and programming paradigm debates), but BDD has left a gnawing uneasiness in the back of my mind - generally this mind chewing begins when I'm missing the bigger picture or when something just isn't right. I got a chuckle out of Spolsky's writing as he discusses specification frameworks:

the geeks ... focus on things they can see in the code, rather than waiting for the users to judge. They’re programmers, so they try to automate everything in their life, and of course they try to automate the QA process. This is how you get unit testing ... In order to mechanically prove that a program corresponds to some spec, the spec itself needs to be extremely detailed. In fact the spec has to define everything about the program, otherwise, nothing can be proven automatically and mechanically. Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.

Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. - Talk at Yale: Part 1 of 3, Joel Spolsky

Hehehe... Anyhow; I need to cut this post short. My DIY Nuclear Fusion Reactor and perpetual motion machine are calling my name. Errrr... I mean, I need to continue working through the RSpec book and playing around with other specification frameworks, because there's always value in learning something new.

Author: Adam Kahtava Categories: Software, Testing Tags:

The Three-step Sequence: Incorrect Assumptions and Experience

September 30th, 2008

the obvious ... is never seen until someone expresses it simply. - Kahlil Gibran

The preface of Object Oriented Software Construction literally introduced me to the three-step sequence:

the well-known three-step sequence of reactions that meets the introduction of a new methodological principle:

(1) "it's trivial";
(2) "it cannot work";
(3) "that's how I did it all along anyway".

(The order may vary.) - Bertrand Meyer

Naturally people consider themselves smart, which sometimes translates into knowing everything, and these three reactions are probably a manifestation of thinking you're overly enlightened. If we put ego aside - along with our natural predisposition for being lazy (trying to avoiding learning new things) - we often change our views altogether.

Looking back at my technological naivety: I was once wrongly convinced that client-side languages would never work and server-side languages / frameworks would dominate (until I really learned JavaScript), I had also mistakenly assumed that I was already doing TDD (until being introduced to the concept of Mocking), and I even thought that HTML table based design was the future (until I really learned CSS). With a little bit of knowledge and some experience I changed my views altogether.

Reflecting on these incorrect assumptions and decisions promotes growth - with every experience we grow. Which of my latest assumptions / reactions will change over time?

Author: Adam Kahtava Categories: Book, Musings, Personal, Software, Testing Tags:

Alberta TechFest 2007 was a success : My highlights

November 12th, 2007

This past weekend I attended the Alberta TechFest (an event put on by Calgary .Net User Group). TechFest resembled a code camp, but provides more seminars / sessions geared at a higher level. The sessions were geared towards: project management, the big picture of the Agile process, open source alternatives, as well as some in depth (show me the code type) presentations on Mock objects (using Rhino Mocks), Microsoft's new Acropolis framework, Test Driven Development (TDD), and Refactoring.

My highlights:

  • The session on Agile Project Planning With User Stories, and Refactoring Automated Unit Tests Using Test Smells and Patterns presented by Gerard Meszaros. I've been on a couple projects that could be characterized as "Bad Agile", so Gerard's presentation hit many chords, one of the comments he made really stuck out. He said something like: "it's not about the Agile process, it's about the results, it's about delivering...don't be dogmatic". Sure it's obvious, but it's nice to hear it from someone else.  I'm currently in the process of purchasing Gerard's book: xUnit Test Patterns: Refactoring Test Code.
  • Mock objects with Rhino Mocks was another great session (by Shane Courtrille). I've been using Rhino Mocks for a couple months now, but there's always so much to learn from someone with more experience.

I'm trying to make it a point to attend more of these events in an effort to expand my community.

Author: Adam Kahtava Categories: .NET, Calgary, Code Camp, Events, Musings, Software, Testing Tags:

Quality Assurance: Unit Testing: Test Driven Development (“TDD”): “Write the test first”

July 19th, 2006

The quality assurance (QA) activities in software development generally include: defect tracking, Unit Testing, source-code tracing, technical reviews, integration testing, and system testing. Out of these activities: Unit Testing, source-code tracing, and integration testing are informally left to the developer. Out of these three developer specific activities, Unit Testing seems to be the most overlooked and misunderstood activity with the greatest potential for improving the development process (improving quality, efficiency, etc...).

The procedure [for Unit Testing] is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. - Wikipedia: Unit_testing

By writing good unit tests and employing a good Unit Testing framework you can significantly improve your software development cycle. By writing unit tests you decrease your dependency on a debugger, decrease source-code tracing (debugger walkthroughs), and so on. And by employing a good Unit Testing framework you can begin to lay the scaffolding for other forms of developer specific testing (integration, system testing, and even GUI testing). Unit Testing also contributes to better documentation - if a developer doesn't understand the purpose of a component they can now read an additional piece of documentation, the unit tests. Unit Testing and Unit Testing frameworks can bring a team of developers to the same level - the capabilities within a team vary by developer. By using the same underlying framework, by identifying general areas that always need Unit Testing we develop a heuristic approach to testing and with that, test patterns, and a new vocabulary to assist with inter developer communication - design patterns accomplish a similar goal. Marc Clifton has a tutorial on Unit Test Patterns.

Unit Testing has its flaws just like any other technique or methodology - there are no silver bullets. Unit Testing is contingent on GOOD unit tests - it's just as easy to write bad code that works, as it is to write bad unit tests that pass (work). Unit Testing won't catch every error, but that's the reality of writing programs, it's also why we have a large number of software testing (QA) activities - writing software that is 100% bug free is impossible. These are just a couple issues with Unit Testing.

[Test-Driven Development is] a computer programming technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. The goal of test-driven development is to achieve rapid feedback. - Wikipedia: Test-Driven Development

The Test-Driven Development (TDD) programming technique is fundamental to many of the Agile methodologies - particularly the Extreme Programming (XP) methodology. The TDD approach uses Unit Testing as a process for designing and testing software. The core idea behind TDD is to have the developer "write the test first" then write the code to pass the test. The technique forces the developer to "thinking before acting" which is really a "best practice" advisable for everyone - I would hope that "thinking before acting" is practiced informally by most experienced developers, but that's often not the reality. Other programming techniques that revolve around the "thinking before acting" idea include: the Pseudocode Programming Process (PPP), and the Program Design Language (PDL) Both the PPP and the PDL have gained exposure through Steve McConnell's book Code Complete.

The mature unit testing frameworks that have gained popularity through the TDD / XP community are important; unit testing through these frameworks will compliment any quality assurance plan and improve any development process.

For more information on Unit Testing and TDD see the following:

Author: Adam Kahtava Categories: Quality Assurance, Software, Testing Tags:

Quality Assurance: Advanced Unit Testing: NUnit

July 17th, 2006

Marc Clifton has a great five part series on Advance Unit Testing. Throughout these articles Marc builds a Unit Testing framework based on the NUnit framework - NUnit is a Unit Testing framework for Microsoft .NET, it's very similar to the JUnit framework for Java. Marc explores Unit Testing, the interworkings of Unit Testing frameworks, and the XP methodology.
Don't be intimidated by the number or size of these articles - most of the content is source code.

  • Part I: Introduction to unit testing and a case study taking the XP process up to the point of writing some unit tests
  • Part II: Implementation of an NUnit look-alike and developing the case study further with real tests and real code
  • Part III: Implementation of NUnit extensions, revising and progressing with the case study
  • Part IV: Using reflection to create unit tests that are script based instead of code based, and the impact of that on the case study
  • Part V: Unit Test Patterns