Podcast: Mock Objects and Unit Testing

Testing and designing with mock objects

Welcome to the second half of this unit testing podcast series.

Last week’s podcast covered some unit-testing tips and JUnit patterns. This week covers mock objects – the how and why,

Click to download the Podcast. You can also subscribe to the feed if you want future podcasts automatically downloaded - check out the podcast FAQ at http://podca.st.

This is a Podcast – a blog entry with an embedded MP3 link. On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod – it’s easy, open, and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/podcast/rss2”. Too easy! 15 minutes and you can be subscribed to receive thousands of MP3 podcasts – from official BBC documentaries to business personalities like Sun COO Jonathan Schwartz to scores of amateur publishers speaking about their own interests. They will download straight to your PC as soon as they’re published. You can listen to them on your PC or any portable MP3 player. If you have an IPod, programs like IPodder will push the downloaded MP3s straight into ITunes, so you can leave home each day with new content loaded on to your IPod. More info in the Podcast FAQ.

Podcast: Testing and JUnit

From the cashing-in-on-ITunes-4.9-hype department, the first podcast in ages.

This time, first of two parts on testing and JUnit. Random apologetic waffle and some announcements at the beginning, main content begins 8 minutes in.

Main thing is, much much less processing and upfront planning so as to just get more of these things out. So if it sounds a bit, err, “spontaneous”, do not adjust your ipod.

Testing and JUnit

Announcements

Click to download the Podcast. You can also subscribe to the feed if you want future podcasts automatically downloaded - check out the podcast FAQ at http://podca.st.

This is a Podcast – a blog entry with an embedded MP3 link. On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod – it’s easy, open, and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/podcast/rss2”. Too easy! 15 minutes and you can be subscribed to receive thousands of MP3 podcasts – from official BBC documentaries to business personalities like Sun COO Jonathan Schwartz to scores of amateur publishers speaking about their own interests. They will download straight to your PC as soon as they’re published. You can listen to them on your PC or any portable MP3 player. If you have an IPod, programs like IPodder will push the downloaded MP3s straight into ITunes, so you can leave home each day with new content loaded on to your IPod. More info in the Podcast FAQ.

Podcast+Text: The AJAX Web Architecture

This podcast discusses AJAX, an architectural style for web applications that has become popular in recent months.

Click to download the podcast mp3

This is a Podcast – a blog entry with an embedded MP3 link. On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod – it’s easy, open, and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/podcast/rss2”. Too easy! 15 minutes and you can be subscribed to receive thousands of MP3 podcasts – from official BBC documentaries to business personalities like Sun COO Jonathan Schwartz to scores of amateur publishers speaking about their own interests. They will download straight to your PC as soon as they’re published. You can listen to them on your PC or any portable MP3 player. If you have an IPod, programs like IPodder will push the downloaded MP3s straight into ITunes, so you can leave home each day with new content loaded on to your IPod. More info in the Podcast FAQ.

Quick Overview

Traditional webapps continue to send pages in their entirety, upon each user request. Consider a wiki such as Wikipedia:

  • User changes some text
  • Browser submits the new text
  • Server saves the text and sends the entire page again, updated this time
  • Browser clears previous page and draws all of new page

AJAX apps don’t redraw the whole page. Instead, they send a little request, receive a result, and adjust the page accordingly. The wiki of the future will look like this:

  • User changes some text
  • Browser submits the change
  • Server saves the change and sends a confirmation and maybe the latest timestamp.
  • Browser adjusts any information, e.g. shows the new timestamp.

For a glimpse of wikis to come, check out this Instant Edit webapp. Fire it up in two different browsers and see how the changes persist without reloading the page.

Most famously, Google has a few AJAX applications: Google Maps, GMail, Google Suggest.

YARC! Yet Another Rich Client!

AJAX, and the underlying XMLHttpRequest object, is the latest approach in the tradition of enriching the web platform. To put it into perspective, here are a few other attempts at rich applications over the years:

  • In the early 1990s, the Mosaic browser made the web clickable. It was the first window-based browser.
  • Images, then animations and sounds, were later added. ASCII art soon faded as quickly as silent film.
  • Java allowed for client-side applets.
  • Javascript (no relation) allowed for embedded programming inside HTML and led to a dramatic rise in cross-browser compatibility tables.
  • Flash was introduced, and with Flash MX, became more programmer-friendly.
  • Client-side GUI applications increasingly connected to the internet. e.g. Multiplayer games, Desktop search tools, ITunes Music Store, Auto-updating virus protection, Dreaded “free” spyware.
  • Frames, and even better, invisible IFrames allowed for invisible request submission and manipulation of the current web page.
  • Each browser continues to offer its own proprietary extensions (with some possible clicking of checkboxes or downloading of extra components): MS offers .NET support, Mozilla and Firefox offer a powerful plugin architecture, Opera offers a presentation package.

The Heart of AJAX: XMLHttpRequest

AJAX is a new name (Feb 2005) for a design style that has been possible, and in fact used sparingly, for the past couple of years. The underlying technology is XMLHttpRequest, a Javascript object that supports web requests. Every big modern language has a class like this: it takes a URL, fetches the content, and provides query support. XMLHttpRequest supports standard text as well as XML documents. That means a web page can wait for Javascript events, submit info to a web server, catch the resulting output, and play around with the current page.

One more thing about the technology: the request-response cycle is asynchronous. The XMLHttpRequest object is registered with a response handling Javascript function, and fires off to the server. Some time later, the server probably comes back, and the registered function catches the result. And that’s what AJAX stands for: Asynchronous Javascript + XML.

Let’s look at an example: This chat application is based on AJAX. You can see the Javascript here. (The entire thing has a Creative Commons license.)

When the user says something, the function sendComment() is called. It grabs the user’s message from the input field and passes it to httpSendChat, an XMLHtppRequest object. httpSendChat posts it to the server.

 
    httpSendChat.open("POST", SendChaturl, true);
    httpSendChat.setRequestHeader('Content-Type','application/x-www-form-urlencoded');
    httpSendChat.onreadystatechange = handlehHttpSendChat;
    httpSendChat.send(param);
 

The emphasised line is the registration: it says that the response will come back to the handlehHttpSendChat function. That function will discard any partial responses, and upon receiving a full response (state=4), it will redraw the chat (which involves another trip to the server):


function handlehHttpSendChat() {
  if (httpSendChat.readyState == 4) {
    receiveChatText(); //refreshes the chat after a new comment has been added (this makes it more responsive)
  }
}

receiveChatText() calls the server to send the recent discussion history, and ensures the response goes to handleHttpReceiveChat(). That function rearranges the chat text according to the recent message:

function handlehHttpReceiveChat() { if (httpReceiveChat.readyState == 4) { results = httpReceiveChat.responseText.split(‘—‘); //the fields are separated by — if (results.length > 2) { for(i=0;i < (results.length-1);i=i+3) { //goes through the result one message at a time insertNewContent(results[i+1],results[i+2]); //inserts the new content into the page } lastID = results[results.length-4]; } …. }

Great, it works if I say something. But it’s a chat program. What if someone else says something? The application simply polls the server, ensuring that “receiveChatText” is called every four seconds.

All About Usability

The chief beneficiary of AJAX is the user. Web applications feel much more responsive, and the user won’t hesitate to perform actions for fear of slow response times, or outright timeouts. Furthermore, form data need not be lost due to browser crashes: using a timer, it can be sent to the server every few minutes, just like auto-backup.

For standard form-based applications, that’s a nice benefit, but hardly a killer app. Where AJAX will shine is in truely rich applications. In particular, on intranets, where many corporations have already migrated traditional GUI applications. This migration process has usually been led by technologists concerned with the infrastructural overheads of administering and upgrading standalone applications. It’s much easier to have all the applications sitting on the server and the clients running a standard web browser.

These web migrations may have improved administrability, but they have often cause users pain. Ironically, they’re often left longing for applications written a decade before the web apps. It doesn’t help that most projects are clueless with regard to usability, but even if usability is considered, the web platform is inherently unusable. The control components are simplistic and server synchronisation is confusing and time-consuming. AJAX doesn’t do anything for the controls, but at least it brings the server and client closer together.

Problems with AJAX

Some objections are taken from the resources below, especially AJAX: Promise or Hype.

It’s Hard to Code

Any Javascript usually makes life more difficult, and early discussions indicate AJAX is no different. At present, coding for AJAX may well be more difficult, although if you look at the code examples around, you’ll see that you’re not exactly facing a Turing Test either. In any event, it’s inevitable that design patterns and supportive frameworks will emerge. A few frameworks already facilitate this mode of development: the always-controversial, uber-funky Ruby On Rails, JSON-RPC-Java, Dynamic Web Remoting. SAJAX, Echo 2. Fortunately for evolution, a wide variety of approaches is being taken. Cross-fertilisation will undoubtedly follow.

In particular, the best frameworks will probably generate as much Javascript as possible, so developers don’t need to co-ordinate between Javascript and server-side controllers.

Testability May Suffer

It’s nice to be able to perform system tests with a robot like httpUnit. Any use of Javascript makes that more difficult. At the same time, because AJAX promotes a more component-based architecture, unit testing may actually be improved. With a good design, it should be quite feasible to test the scripts that are accessed by the XMLHttpRequest object.

Accessibility May Suffer

Any form of interactivity is often anathema to many different types of specialised needs. Nevertheless, this should not stop the technology from progressing, and providing rich interaction to those who can use it. As always, accessibility must be maintained, and multiple mechanisms might be required. Furthermore, new technologies can improve accessibility too. It’s easy to imagine, for example, how an AJAX-enabled site could let users quickly resize and move around certain screen elements to meet their individual needs.

AJAX Will Collapse the Network

AJAX does represent a potential challenge to networking infrastructure. Traditional web applications can feel like earlier client-server applications. Submit your offerings, then receive a response and meditate on it for a while. AJAX makes the term “web application” a lot more honest. The server really is involved, possibly even after each keystroke. Interestingly, bandwidth requirements may go down because usually only small changes need to be sent each way. However, latency is another question: using an AJAX application might feel like typing against a slow telnet connection. Stuff… hap…pens…much…sl..ower…than you…can…think… .

This will probably not be a major concern on intranets, where there are relatively few users and usually good connectivity to the server (especially as it’s often nearby). However, it’s still an open question how AJAX will be used on the public web. Certainly, it can be used to incrementally improve just about any form-based application. And it can surely go beyond that, as Google demonstrates. But can it scale to the requirements of a major site, offering a fully-scaleable wiki or genuinely playable gaming?

It’s Just a Name, the Tech’s Not New At All

XMLHttpObject has been around for a few years, but it would be hard to believe anything called “XMLHttpObject” could trigger a revolution on the PCs of the world. Frames and IFrames supported this sort of interaction even earlier. History and logic would suggest that a standard name and community, combined with some flagship applications, are powerful tools indeed. And the timing is right: users have lived with static web applications long enough, broadband is now mainstream, and the economy hungers for innovation. The raw technology may have been around, and even used in doses. But all signs indicate that the new name, given the increased need and the prominent offerings by Google offerings, constitutes a tipping point.

Bill Won’t Like It

Let’s be clear. This could have happened a lot earlier. There’s a lot of unfounded nonsense about MS on the web, but there is indeed broad agreement that MS does not benefit from adoption of rich web applications. And for pretty obvious reasons. They worked hard to innovate with IE in the mid-90s, attaining the dominant position. Consequently, they managed to crush Netscape’s dreams of replacing the Office Suite and Sun’s dreams of Java on every desktop. It’s hard to see MS doing anything about XMLHttpRequest within IE though; the interaction it provides is rich, but quite frankly, not that rich.

Flash Can Do All This, and More

Flash is a bit of a mystery, since it’s extremely cross-platform, having excellent support on all the major browsers and platforms. And yet, it’s never taken off for serious application work. In fact, it’s really been used for not much more than ads and fancy presentations. It’s certainly capable of doing much more serious applications, and maybe Flash MX will still shine. It took a long time for Macromedia to target serious development. Perhaps this was a strategic mistake, or perhaps it was an intentional means of gaining wide browser share.

Examples

Further Resources

Agile Software Riffcast 4 of 4: The Dark Side of Agile

Here’s the final of four podcasts on agile software development. If the first three got you buzzed about cutting code the agile way, and you’re pumped up to do it, and you’re just bursting to get out the gate … this one will make you think twice. It’s not all roses you know! In the spirit of pragmatism, it’s important to be aware of the strengths and weaknesses of many different approaches. So this podcast looks at the flaws and challenges for agile software development.

Click to download the podcast mp3

This is a Podcast. On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod – it’s easy and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/wp-rss2.php”. Too easy! 15 minutes and you can be subscribed to receive thousands of MP3 podcasts – straight to your PC as soon as they’re published. And also your IPod if you have one, or you can listen on any other portable player. More info in the Podcast FAQ.

Show notes for this podcast:

  • Methodologies: Pragmatic good, dogmatic bad.

  • Sources:

    • Personal and others’ views and anecdotes.
    • McBreen’s Questioning Extreme Programming
    • Stephens and Rosenberg’s [Extreme Programming Refactored]
    • Polite commentary and outright flame wars on forums such as Usenet.
  • Non-starter problems: (traditional complaints where agile has reasonable comebacks)

    • How can we keep quality high if the software keeps changing?
    • What if staff leave?
  • Open problems: (further complaints which I feel still need to be answered):

    • Limited project size and criticality
    • Continuously changing non-functional areas
    • Gathering requirements without business analysts
    • Can be more demanding: more social interaction. (see Kathy Sierra’ blog entry on pair programming and loner personality types).
    • Might work for developers, but does it fit with external stakeholders (managers, clients, auditors, users)?
    • Billing model: time-and-materials versus fixed-contract.
    • Flatter structure: how about less talented or motivated staff?
    • Can be used as an excuse for hacking (not a criticism of agile per se, but where’s the boundary?)
  • XP-specific problems:

    • Fragile: Can’t always apply all practices, and leaving one or two out can cause project to collapse
    • Why always pair? Some tasks benefit more than others.
    • Collective ownership: who’s responsible?
  • Discussion:

    • (With apologies to Churchill) For many typical projects, agile may be the worse methodology … except all the others.
    • Moreover, avoid direct comparisons and be pragmatic: Treat methodologies as a palette of tools and techniques. Know them well, and take on whatever fits your current needs.
  • Agile Series Wrap-Up.

Agile Software Riffcast 3 of 4: Extreme Programming

Click to download the podcast mp3 On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. You can subscribe for updates straight into your PC or ipod – it’s easy and free. Refer to the podcasting FAQ at http://podca.st.

Here’s the third of four podcasts on agile software development. The first – an overview on agile – is available here and the second – a survey of methodologies – is here. This 37-minute podcast focuses on the best known – and most controversial – of the methodologies: Extreme Programming.

Show Notes:

  • About embracing change, a rapid departure from plan-and-build.

  • So don’t just tweak traditional processes … reinvent them.

  • Four core values:

    • Feedback
    • Communication
    • Simplicity
    • Courage
  • Twelve practices:

    • The Planning Process. Elicitation by negotiation and ongoing discussion; specification by index cards rather than exhaustive documents.
    • Small Releases. 1-4 week iterations.
    • Simple Design. Minimalist approach. Simple, not stupid. Once and once only. "You Ain’t Gonna Need It".
    • Metaphor. Cohesive design.
    • Testing. JUnit.
    • Refactoring. "Refactor mercilessly."
    • Pair Programming. Constant review improves design and testing, enables collective ownership.
    • Collective Ownership. Keeps tacit knowledge spread across team, supports refactoring and ongoing design improvement, acts as contingency against staff departure.
    • Continuous Integration. Ensures code can change quickly, keeps developers’ attention on adding business value rather than micro-managing infrastructure.
    • On-Site Customer. Allows tacit requirements.
    • Coding Standard. Supports collective ownership.
    • **40-hour Week. ** "Sustainable Pace"
  • Origins:

    • C3 project
    • Smalltalk and unit testing
    • Design patterns
  • Stayed tuned for the next podcast, the final in this Agile Software Riffcast series: The Dark Side of Agile.

Thanks again to My Morning Jacket for the sample used in the lead-in track.

Agile Software Riffcast 2 of 4: The Methodologies

Here’s the second of four podcasts on agile software development. The first is available here. This 42 minute podcast is a survey of six methodologies and the men (yes, they are) behind them.

The methodologies discussed are (with creators or prominent proponents parenthesised).

  1. Scrum (Ken Schwaber)
  2. Crystal. (Alistair Cockburn) And here’s a link to Alistair Cockburn’s thesis that I mention.
  3. Pragmatic Programming (Andy Hunt and Dave Thomas)
  4. DSDM (DSDM Consortium)
  5. Lean Manufacturing(Poppendieck and Poppendieck)
  6. Extreme Programming (Beck)

Click to download the podcast mp3 Thanks to Tim Madden (via forret.com) for the icon. And thanks again to My Morning Jacket for making the lead-in track.

(Oh and all the best for 2005.)

Podcast: Interfaces As Services

  • Update: Podcast missing *

Enclosed is a podcast on interfaces as services. Agile Business Coach, Chris Matts, blogged a couple of times this week about how interfaces should emerge by looking at the objects that use them. I agree, and wanted to give my own thoughts. Important concept, as it’s driving many trends in architecture: dependency injection, Spring/Pico, mock objects.

Click here to download or listen: InterfacesAsServices.mp3.

BUT (and I’m going to keep saying this), if you haven’t yet got into podcasting, get yourself over to ipodder.org. You don’t need an IPod … a computer or any other mp3 playing device will do. You’ll be able to subscribe to a feed of all updates of this show and any others you’re interested in. All open and free. More info at Podca.st.

Once again, this podcast includes a sample from My Morning Jacket’s “One Big Holiday”.

Feedback always welcome – mail me an MP3 or text.

Agile Software RiffCast

Agile Software Riffcast

Here’s my first podcast. In my podcasts, I’ll mostly be covering software development topics such as architecture, usability, design patterns.

This is the first of four “Riffcasts” where I’m riffing on the topic of agile software development. The series will contain:

  1. Agile software development overview. Embracing change and the Agile Manifesto. (The podcast enclosure on this entry.)**
  2. Survey of agile methodologies and perspectives. Including Scrum, Pragmatic Programming, Crystal, DSDM, Lean Manufacturing, Extreme Programming.
  3. Extreme Programming. More detailed look at the most famous (or notorious, depending ) Agile Methodology, Extreme Programming.
  4. The Dark Side of Agile. Problems with agile approaches, situations where it does and doesn’t work, open questions.

My plan is to publish these roughly once per week, but the beauty of podcasts (as with blogs) is that I can upload them when I like, and subscribers will have them soon after. Unlike traditional radio, they don’t need to be sitting there at the time I “broadcast” it. So I’m going to see how things pan out.

I’m going to do stuff in parallel with these “Riffcasts”, all on the same “Software As She’s Developed” stream. Such as more “Blogcasts” of a more general nature.

Really, really, keen for your feedback, especially ingratiating syruppy praise! [email protected]

The MP3 File

You can hear the podcast by clicking here. But long term, there’s a much better way …

Subscribing to this Podcast

How can you subscribe to this stream, so you can have this and all my future podcasts automatically downloaded (as well as hundreds of other shows)? Easy – download ipodder (or any other podcasting client) and simply add this feed:

  • http://www.softwareas.com/podcast/rss2/

ipodder and the hundreds of podcast programs are all free, BTW.

Credits and Copyright Bits

This podcast is licensed under the same Creative Commons license you find attached to softwareas.com. Basically, this means you can do whatever you like with it as long as you say how awesome I am. (I think that’s the gist of it, but the full details are here). The lead-in track is a sample of My Morning Jacket’s “One Big Holiday”, who were among the enlightened artists who contributed to the Wired CD. Thanks to the band, Creative Commons, and Wired for making it possible.

They dreamed of a brave new world of sharing and liberty. I superimposed a quality track onto a stream of geeky rambling.