Elements of Testing Style

It's been way too long since I blathered on about style issues. Today I'd like to talk about testing style. This article assumes you are already writing tests and already using something approaching a Test-Driven Development process -- I'm not here to argue about process, at least not today.

Today the topic is the actual construction of individual tests, how to name them, how to group them, where to get data from and the like.

I suspect I'll think of five more things right after I post this, so look for an update sometime in the future. The update will also address all the places where everybody tells me that I'm totally wrong.

Self-promotion alert: More details about Rails testing can be found at Rails Test Prescriptions, there's a free getting started tutorial which contains an extensive section on Cucumber, and a nearly 300 pages and counting full book for $9. Thanks. Also, follow @railsrx on Twitter for a testing tip every weekday.

Continue reading »

Topics:

Asterisk-Java Testing with Groovy

iPhone in Dock

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy-- specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes...

Continue reading »

Fluently NHibernate

logo

Fluent NHibernate is an extension of the widely used and very popular NHibernate framework for Microsoft .NET. It is an open source framework that sits on top of the NHibernate layer and utilises all the core NHibernate methods. This framework provides an alternative to the standard XML based mappings (.hbm xml files) of NHibernate. It lets you define the NHibernate mappings in strongly typed and concise C# code.  For those who are new to NHibernate, here is more information.

Continue reading »

Digging a Hole and Covering it with Leaves — The Software Development Version

Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We're digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).

No, this isn't a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan -- usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it's own and becomes a long-term deliverable, that's when you run into problems. What are these problems? They aren't as numerous as fall leaves, but there are plenty.

Continue reading »

The Importance of User Experience - Do You Understand It in Your Bones?

Business Week had an article earlier this week on Cloud Computing that made a complete hash of the subject. However, there was one paragraph that was right on the money:

Apple and Google understand in their bones that simplicity and ease of use are essential to broad adoption of products and services. That lesson doesn't come so naturally to Microsoft and IBM.

That's why we integrate user experience design into the agile development process, and that's why we advise our clients to release the simplest software they can early, so they can learn from real user feedback and continue to make improvements based on that learning.

It's like John Gruber writes over at Daring Fireball:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
John Gall

If there’s a formula to Apple’s success over the past 10 years, that’s it. Start with something simple and build it, grow it, improve it, steadily over time. Evolve it.

Do you understand that in your bones?

Feature Fatigue

Your project is going along fine. After the initial bumps, the team has reached max velocity and is running through story points like there’s no tomorrow. The demos are a success, with the client loving how everything is coming together. Communication between the team members and the client is working well, with enough give and take that all sides feel like they have a genuine stake in the project. In fact, the goal posts are in sight and we’re already scheduling a release plan. And then the client asks for one more feature. Not a tweak of something already built, but a new feature that has to seamlessly incorporate into the application and not look like a last minute add-on.

The initial response? The team to comes to a screeching halt and devolves into something resembling the stages of grief. Continue reading »

Agile Fundamentals: The Feedback Loop

When you improve a little each day, eventually big things occur. -- John Wooden

A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted -- that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.

Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don't like it.

These [thirteen] practices support one another...and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:

  1. Feedback loop
  2. Feedback loop
  3. Feedback loop

Continue reading »

Integrating Design and Agile Development

If you liked my colleague Alice Toth's presentation on Agile Requirements, you'll like her talk on integrating design and agile development:

AGILE AND ME a story with just enough documentation.

A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.

While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements? Here's how we do it at Pathfinder:

Like what you see? Check out more of Pathfinder's presentations, whitepapers and articles here.

What value isn’t

"I have tried Campfire, and I'm still not quite sure why people pay for it. I think you can take simplicity too far personally. It could be replicated on a weekend (As was done at google with huddlechat) so I don't see the value proposition there." Source

With apologies to Mike Godwin, I like to think of the following as Nolker's Law: As any technical discussion of a web 2.0 product grows longer, the probability of a claim that it can be built in a weekend approaches 1.

Continue reading »

Topics:

How to learn a new programming language or framework

bunny_tutorial.jpgWhile never untrue, it is more of a necessity now, that a programmer should know more than just one language or framework. After being a focussed Java/J2EE developer for a long time since college, in the last couple of years, I plunged into .NET, Ruby/Rails and then Javascript/prototype/jQuery etc and now onto groovy/grails. With name like Erlang, Scala, Compass, git, blueprint, flex flying around us everywhere, it can be overwhelming and we need a plan to pick, peruse, acquire them. Here is a list of things I do when learning a new skill.

Continue reading »

GWTUML - Just Enough UML for Wikis

r243screenshotFlorian Mounier has spent the last six months developing GWT UML, a slick little UML diagramming tool written in, obviously, GWT. It's smooth, good looking, supports class, object and sequence diagrams. You can save your diagram as a url or export it to an SVG. You wouldn't try to do model driven development with it, but for embedding in a development wiki, this thing could rock.

You can find more information at the google code project and check out a demo here.

Topics: ,

37 Signals on Launching Softly

Over at Signal vs. Noise, sound advice on the advantages of launching softly:

... You don’t need a big bang – slow evolution is what you want. Unless you absolutely must “open wide,” abandon the mass introduction strategy. Instead, launch softly.

Restaurants start off by serving friends and family before they invite the media.

Movie studios use test screenings to fine tune movies. The people behind the scenes know that until you get into the test screenings and see what people really think, you just never know.

Likewise, Jerry Seinfeld and Chris Rock try out jokes in small clubs before hitting arenas...

Soft launching lets you tweak and revise. You get the word out there and you gauge interest. You know what works and what doesn’t.

Plus, you get to make mistakes while you’re still in the shadows. Messing up in front of a smaller crowd means you’ll be better off when the bright lights eventually do shine upon you.

Dead on, as usual, from the authors of Getting Real.  It's what we advise clients and prospects, and when they follow it, their chances of success dramatically increase.

Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall.

niagararocks

Agile development, when done right, results in better software are a lower cost. More and more companies are coming to this conclusion, but most are struggling with how to adjust their RFP and Governance processes to adapt.

The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI. History clearly shows this is not true. Issuers expect to come within 10-20% of budget. Studies show that custom software costs can range from 50% under budget to 300% over budget. Why?

  • Requirements are usually inadequate (though there is a very wide range if inadequacies.)
  • The requirements produced generally have little to do with usability.
  • Things change – requirements change, technology changes, the competition changes, etc.
  • Too many features are built that aren’t used – studies show that 45% of features build under waterfall are never used.

Because all vendors know the above, they all take different approaches to responding to RFPs. Some try to provide a relatively accurate estimate by using historical patterns. This can be fairly accurate if they’re building an application they have done many times before using the same technologies.

Continue reading »

The Return of the Cucumber

I mentioned last week that the RubyMine post was replacing what I had meant to write about. Well, this week we finally get to it...

It's been about ten weeks since I wrote about Cucumber the first time and the second time. Since then, I've continued to use Cucumber and now seemed like a good time to update some thoughts on how and why it seems to be working for us.

The big headline, of course, is that I'm still using it after ten weeks. I'm pretty quick to abandon tools that aren't pulling their weight, so just the fact that Cucumber is still in the toolbox means that despite the time that it takes to write Cucumber tests and step definitions, I'm finding the process of writing the tests and the tests themselves to be valuable.

Self-promotion alert: More details about Cucumber and anything relating to Rails testing can be found at Rails Test Prescriptions, there's a free getting started tutorial which contains an extensive section on Cucumber, and a nearly 300 pages and counting full book for $9. Thanks. Also, follow @railsrx on Twitter for a testing tip every weekday.

Continue reading »

Death to IE6

“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”

~ Jeff Zeldman, standards guru

death to ie6Anyone who has worked with developing the presentation layer for web apps has become quite adept at creating workarounds in JS and CSS to try and give the user the same experience in IE6 that they’d have if they used an up-to-date browser. However, because of IE6's non-compliance with W3C Standards, a ridiculous amount of extra work (i.e., hacks) is needed in order to get the page to render correctly in this most outdated of browsers. And, as Dietrich mentioned in a previous post, the problem is that these deviations from the standard end up becoming the standard and increase the amount of time required to write and maintain code.
Continue reading »

Topics: ,

About Pathfinder

Follow the Blog

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email

      

    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com