Category Archives: interfaces

interfaces, TDD, test-driven development

Expressing Interfaces

Mark McSweeny comments on Discovering Interfaces:

While testers work to discover interfaces in programs, developers work to express interfaces. This can be through developing an API, an interface for unit testing, all the way down to the data structures and algorithms you use. Well designed interfaces are testable interfaces, so a tester can tell you whether the interfaces you have expressed are testable or not.

The meeting of the roles through the program is interesting to me. The two meet in the middle of creation and inquiry. Sometimes as testers we forget that there are people behind what we are testing who have poured a lot of effort into the interfaces we are testing. The more testers can supply positive feedback to the developers, the more confidence they can get from their development efforts.

While testers may be satisfied when a program does not fail after they have attempted to make it break, a developer is satisfied when they have solved a problem using technology. Together, there is expression, inquiry, discovery, feedback, communication, and collaboration.

What is interesting with methods such as TDD is that they attempt to combine interface expression and discovery. One attempts to express an interface while also attempting to critique it.

design, interfaces, testability

Discovering Interfaces Continued

James Bach responds:

Testing is an exercise in discovering a lot of things, including interfaces. But it is more than just discovery, it is inquiry. Inquiry is action; discovery is an event. Inquiry is within my control; not so with discovery. But certainly, good testing involves a lot of discovery and a lot of interfacing.

James raises a good point, and helps clarify the “Discovering Interfaces” test technique. Discovery would follow inquiry, and action would follow discovery. Through inquiry, testers can discover testable interfaces, and look at the feasibility of testing through them. The tester can collaborate with developers and other stakeholders to decide if the project warrants testing at the level of a particular interface, or at another layer in the application. If it looks feasible, testers can begin developing test cases against that testable interface.

This is a technique that I would encourage testers to look at when they are working on test automation strategies. Merely looking at the GUI (the most obvious interface to test against), only shows a thin layer of the application. There are other testable interfaces that in many cases may be better test automation candidates.

For more on test interfaces, check out Bret Pettichord’s article: Design for Testability, and Brian Marick’s article: Bypassing the GUI.

interfaces, TDD, test-driven development, tools

John Kordyback on Testing

Testing is an exercise of discovering interfaces.

If this interests you, think about the above statement, and share your conclusions. I’ll post my own thoughts shortly.

(edit – I’ve added a couple of my own thoughts)

From a development perspective, driving out interfaces and making the code more testable will improve the overall design when following test-driven development. The developers drive out the design with unit tests using a tool like JUnit which helps them create interfaces. But JUnit itself uses an interface to exercise areas of the code. Now things get interesting…

From a tester’s perspective, this concept came clear to me when exploring areas of the application behind the GUI layer to write automated tests against. For example, if a developer makes a particular part of the code testable, we can use some sort of tool to write tests and exercise areas of the code. In this case, we find an area we’d like to test, and the developers create an interface for us to test against. If we create fixtures with FIT, we are essentially creating another testable interface. When we use WTR Ruby scripts to drive the browser via the DOM, we are using the DOM interface to test the application. Screen-scraping automated functional testing tools create their own testable interface.

From this perspective, the difference between JUnit or HTTPUnit tests, FIT or WTR tests or some other testing tool is the type of interface they use.

An interesting side-effect of seeking testable interfaces in a product from the code level up: the more we learn about the interfaces, the more we explore the product and the more we learn about it. The more we learn, the more information we gather about the applications strengths and weaknesses. It kind of sounds like testing software doesn’t it?

We can take a cue from our test-driven developer colleagues and how they use interfaces to design better code, and seek to drive out interfaces to help us test the product more thoroughly. This is another view of testing which takes us away from a strict black-box perspective. Think of peeling back the GUI layer (with web applications it can be simple to peel back the browser and start looking at the HTTP layer and down into the code), and look for testable interfaces, or areas that could use them. You might be surprised at what you find, and a new world of testing may be waiting to be discovered.