Archive

Archive for the ‘Testing’ Category

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:

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

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: