Welcome!

Java IoT Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Kong Yang

Related Topics: Java IoT

Java IoT: Article

Test-Driven Development Is Not About Testing

Test-Driven Development Is Not About Testing

I am always on the look out for good questions to ask candidates in an interview. Not the "How many oranges can I fit in this room?" kind of nonsense (the stock response to which is apparently "with or without us standing in it?"). Nor the picky, encyclopedic type such as "In the javax.obscure.DustyCorner class, which method throws a FullyDocumentedException?" (If you do not respond with "I would check the Javadocs" on the grounds that you actually know, you really ought to get out more.)

Instead, I like the sort of technical question that allows candidates to demonstrate real insight; where they can show not only technical depth and breadth, but also a mature understanding of the software development process. So I was delighted when a colleague offered me a perfect interview question, namely: "What is the point of test-driven development?"

Test-driven development (TDD) has grown out of the Agile software movement (www.agilealliance.org) and Extreme Programming (XP) in particular. Extreme Programming stipulates a set of best practices that collectively encourage core values such as feedback and simplicity. The feedback occurs in the form of tests, by delivering in short iterations, and by the simple expedient of talking to one another. The simplicity comes from the process of refactoring - ruthlessly - and from only delivering exactly what the software has to do right now.

Kent Beck, the original champion of XP, has extracted the essence of its development practices and named it test-driven development. And so to the model interview answer. The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.

We start by writing some client code as though the code we want to develop already existed and had been written purely to make our life as easy as it could possibly be. This is a tremendously liberating thing to do: by writing a model client for our code, in the form of a test, we can define programmatically the most suitable API for our needs. In addition, we assert the behavior we want.

Obviously this won't even compile, and this is the counterintuitive part - the code that will sit on the other side of the API doesn't even exist yet! The next stage is to write the minimum amount of code to get the test compiling. That's all, just a clean compile, so you can run the test (which at this stage will fail). IDEs such as IntelliJ IDEA or the open source Eclipse will generate missing classes and implement missing methods for you. Now, and only now, you write the application code to satisfy the test. The final piece of the puzzle is to refactor the code so it's as simple as it can be. This then becomes your development rhythm: write a test, write some code, refactor.

Writing the test before you write the code focuses the mind - and the development process - on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests.

We keep the tests we wrote and run all of them, often, to make sure the system does everything it is supposed to do (and to alert ourselves immediately if we break any existing functionality). However, the extremely useful test suite we've created is very much a secondary benefit of the TDD process.

So when you're sitting in an interview and someone asks you about testdriven development, remember that it's not about the tests; it's about seeing how little you actually need to do and how cleanly you can do it! If someone asks you to fill a room with oranges? Well, I'll leave that to you.

More Stories By Dan North

Dan North has been writing software for 12 years, and is a programmer and coach for ThoughtWorks (www.thoughtworks.com), a software development consultancy, where he encourages people to write tests.

Comments (21) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Kamal Mettananda 06/13/06 08:49:03 AM EDT

Good article.
TDD is one of the ways that can be used to solve the issue of unclear requirements. Difference between what the customer wanted and what programmgers developed always has been + or -. Most of the time prorammers get confused inside all the requirements and write the code according to their knowledge.

But if the test based mindset is there, the solution gets close to the requirements. The hardest thing to achieve is to develop the correct test set. If the programmers who got confused inside requirements does this as well, then the goal will not be achieved.

William 01/13/05 06:38:58 PM EST

I am a 'code everything that MIGHT be needed in the next 100 years' type of programmer. To date, I have completed 1 program in the last 15 years of programming (this way).
It dawned on me that there is a better way. Having taught for several years, I taught the spiral and waterfall models. The department head hated XP programming. However from personal expierience, I have taken a hard look at my techniques and models I use. Here is what I found:
* Gather your requirements, and note dependancies.
* Do a preliminary system design. System design and future forseable changes MUST play a large part of the initial [API] design. This part of the project takes anywhere fom a couple of hours to several weeks, depending on functionality and requirements.
* Code from the user interface back, testing as you go.

This is another view of TDD. Code what is needed, not what might be. I know as I have thrown away more working and tested code than I keep (just to keep dead weight out of the source).

treyst1 12/04/04 02:29:35 PM EST

I agree with CW: "agile development" has become a trigger-word for knee jerk reactions. At its most simple, agile software development focuses on continuous care of design: what's not to like about that?

Walter 12/04/04 01:49:37 PM EST

Nice article -- thoughtful comments.
My view of value of TDD is in driving the requirements to completion. Especially useful if the tests are validated by the stakeholders. However, no small number of tests, and in many cases no finite set of tests, can be a complete specificaiton. So there is always 1 more bug.

Arup 12/02/04 11:59:00 AM EST

The word Agile itself means being able to adapt / changes itself according to the context. The kind of methodology that should be used should depend on the project requirements, there is no one stragey suits all magic formula.

I see over the last few years we are exactly making the same kind of mistakes with XP that we did with earlier methodologies by mandating a particular way of development.

TDD however gave me another interesting benefit. I am a person who by nature has a habit of over engineering application designs. TDD helps me curb that and helps me make design which are much simpler.

Eivind Eklund 08/02/04 10:05:30 AM EDT

The last post (talking about more work) is missing the point. It is *more code to type up front*, but the clue is to make LESS work.

I find the 2x to 3x more code than the individual methods being tested to about match my own experiences. The efficiency in refactoring and the cleanliness of the code produced, however, turn development of the same functionality into less work (if you measure in terms of development hours). It also make the code much more pleasant to work with afterwards.

Eivind

Simon 08/02/04 08:14:03 AM EDT

Well TDD was all over TechED in the .NEt arena and built straight into the tools, hell nUnit will do it right now. So having the tools to help is a bonus in doing this kind of stuff, centrainly in MS arena. In fact in the new team system rules can be put in place so that code cant even be checked in without a valid test run.

Thing is, moving away from the technical, you mentioned that it is to help with the programmer not writing a bunch of stuff he feels is necessary so only things with a test get through.

Who do you think is writing the tests ? who is auditing the results of those tests ? just how good are the tests in the first place ?

It all sounds good, but, as usual, with pretty much any Xp method you are going to have to put in shed loads of resource to ensure not only the code is correct but the test code is to spec also, with a test for practically every function you could more than double/triple the amount of code to write.

People wonder why corporations are shipping development overseas, with this much effort for every project it better come cheap.

Kevin 05/05/04 11:56:14 PM EDT

Nice article - short and to the point. TDD is definitely about design. But the take-away here needs to be that some amount of design MUST be done up front (in direct contrast to what some are saying). If you don''t think about the interface (i.e. contract) that your software must provide, you can''t even begin to write your test client.

Also, on an unrelated note, I agree with what Sparky says regarding the dangers inherent in a lack of forethought.

Sparky 04/29/04 08:10:52 PM EDT

CW: Where in my comments did I attack any abbreviations or acronyms?

I simply disgreed with the authors statements that you can start coding with only a scant amount of forethought and expect that you will be better able to satisfy all future requirements as a result of that behavior.

Nowhere did I blame his statements on any abbreviations. I happen to like abbreviations.. =8>j)

Regards,
sparky

CW 04/29/04 04:49:49 PM EDT

I''m always amazed when those otherwise innocent abbreviations, like XP or TDD, are mentioned it brings the nay sayers out of the woodwork. Nowhere in this article did the author say, "x must be done y way". Yet when agile development is mentioned, to give background to this piece, many people lose all cogent reasoning and respond emotionally with "that type of development doesn''t work". In fact, nowhere in agile methodology is restrictive guidance documented; quite the contrary, individual developers (or teams) are supposed to TAILOR the agile FRAMEWORK to fit their needs.

This is an excellent article about perspective. Folks who construe it any other way are either managers who do nothing but embrace abbreviations and acronyms without understanding them, or the "legacy" type of people who complain about everything at work without ever offering any solutions!

Sparky 04/21/04 02:40:44 PM EDT

Dan North''s statement that "the system you develop does exactly what it needs to do and no more.. This in turn means that it is easy to modify to make it do more things in the future" is absolutely not true in most cases. In fact, some functionality can never be retrofitted "in the future" if not taken into consideration from the ground up.

It''s a bit irresponsible to suggest that "you should just start coding and everything will eventually work itself out and fall into place." except for a relatively trivial development effort.

(Has anyone seen "The Prototype That Wouldn''t Die"? =8>\)

- sparky

Jörg 04/20/04 04:08:28 PM EDT

Really a nice article.

I am not a XP programmer, but I am not ashame to use refactoring or unit testing where it makes sense. I think it''s good pratice to refactor code to make it both easier to understand and easier to modify.

Wayne 04/16/04 08:20:40 PM EDT

Refactoring sounds like one of those things you can do easily; the sort of thing you do when you don''t want too much of a challenge, but you still want to do something useful to your code. The trouble is that its a bit of a bore when you need to do it. So, you tend to leave the code unfactored and it starts to become a mess. That''s where refactoring tools shine. When you see a need to refactor the tools take away the drudgery so you can concentrate on the intersting part - improving the code.

I''ve only tried refactoring tools on toy applications and I can already see that they are going to be a must have feature in my next development toolset.

Aiden 04/02/04 08:29:31 PM EST

Dan, thanks for the interesting article.

I basically agree with Stuart''s post, except I don''t really get which "tools" are necessary for doing refactoring or unit testing. Do you need more than a simple text editor and compiler?

Neither why it is easier to refactor due to a lack of type declarations. In my experience, the more code the compiler checks for you, the less likely you are to introduce errors.

Eivind Eklund 02/12/04 09:59:09 AM EST

Stuart''s idea that Test Driven Development was not feasible "years ago", due to the lack of refactoring tools. This is represent a misunderstanding. Refactoring is perfectly feasible today without tools - ASSUMING YOU USE THE RIGHT LANGUAGE. I personally mainly use a TDD style when doing development where I can do that. I can''t do it all through my day job yet, due to short-short-short (bi-hourly or similar) deadlines and complex interdependencies. I do not use any particular tools for refactoring. However, I mostly program in languages (Ruby for love, Perl for money) that does not have type declarations. This cuts my code size to between 1/2 (perl) and 1/4 (ruby), and makes refactoring much easier.

I''ll not claim to have done test driven development before it became reasonably well know (I haven''t - I have used tests, but not consistently, and not test first). I have, however, done stuff that is some form of refactoring. I have just not used it as consistently as I do now (all the time, and not as a mix of restructuring and refactoring) nor did it form an as distinct concept in my head as it does now.

Eivind.

Stuart 01/05/04 09:16:08 AM EST

Reading some of the above comments would make me yelp ''Ouch!'', as if someone has smacked me around the head a couple of times. (with the exception of Mr. Putman)

What most people have failed to realise is the point Dan is making, TDD is not about testing - it''s about design. Design does not have to be completed up front, refactoring should be ruthlessly done (if it isn''t broken, let''s pile up some more duplicate code, which isn''t broken), and double negatives prove a point (''An ambiguous API can not never be implemented cleanly'').

The truth of the matter is that although not a complete software development process for large scale projects, TDD will provide you with the simplest solution to your software problem. As the project grows in complexity the tests are a handy extra when it comes to refactoring at a low level. As the user changes his mind about what the software is supposed to do, new tests can be written, old tests can be deleted, code can be changed, and the whole lot refactored.

Is all this a waste of extra effort... of course not. How many times have you worked on a mature project only to have a clever business analyst / user come up and say... we kind of need our software to do this one little simple thing. A ''simple'' thing is business terms can sometimes turn your project upside down. Write a test, write some code and refactor. Try doing that without a test suite and you''re gonna have fun.

And if anyone else mentions that they used to program this way years and years ago... please go out onto a busy street and shout, ''I am a fool!''. There simply weren''t the tools available to program this way before especially with regards to refactoring.

Final note: All of this presumes a developer knows how to write a test. Something that was not particularly clear to me for a while, and took some time to learn. Try to think of testing behaviour, not functionality.

Ben Kuehlhorn 11/25/03 02:09:40 PM EST

I agree that XP is just another development methodology.

Test Driven Development works well when the API is well defined. An ambigous API can not never be implemented cleanly. Critical design must be completed before writing a test case or line of code. The author writes a sample of code to use the API. A lot of detail must be specified for the test to make sense. Any correction or clarification needs to be fixed twice: test case and code. A lot of effort would be wasted without sufficient design.

When does testing end? Do I have to write test cases for my test cases? There is a point to just write the code from a clean, complete design.

Hal Peters 11/14/03 04:27:10 PM EST

Interesting article. It seems some of the concepts from the "old" Top-Down Development and Prototyping approaches have been refactored and are now called XP (Extreme Programming), ASD (Agile Software Development), GEP (Good-enough programming), GP (Guerilla Programming), or what-ever. How much these improve on more "professional" approaches is uncertain, just ask NASA about doing things quickly, cheaper, etc.

Where do USER requirements, pseudo code and decision tables fit into this "new" extremely agile way of doing things? Is Test-Driven Development (TDD) appropriate for industrial strength enterprise applications? YES! If it is managed by professional project managers and it can improve on the horrific success rate of current initiatives. It has been estimated that currently, business users are happy with our computer programming results in only 1 of 3 projects. Be honest, is YOUR experience or your clients'' environment any better?

The point is that with .net, Macromedia Flash MX 2004, ActionScript 2.0, Java, Coffee Beans, Chocolate, and Vanilla all evolving . . . a whole new set of challenges exist. It is imperative that teams learn to embrace tried and true (ie: proven) development techniques, a prerequisite to building more complex applications. We must do thing better and smarter. The goal is to improve the process!

As a closet Methodologist, I say it does not as much matter which Guideline you follow, as long as you and your fellow teammates use (and agree) on ONE!

It must be remembered that with TDD, one needs to keep not only the tests, but the regression test data as well. Resources will now need to be planned for maintenance of these new additions to a project''s software assets.

Refactoring, in general, seems counter intuitive to me. Years of coding experience (starting with FORTRAN2 on the IBM 1620) brings to mind these two adages: - "let sleeping dogs lie" and "If it is not broken, don''t fix it"?

David Putman 11/12/03 07:58:09 AM EST

I sort of saw this article as a clean and concise description of a valuable programming technique which can be used anytime anywhere. I didn''t see any hard and fast rules, just some good, clear, general guidelines.
I know Dan mentioned that the origins of TDD were with Agile Software Development and XP but can''t see anywhere that he says you *have* to be doing these to do TDD. Ditto pair programming.
I think the previous comments missed the point about feedback, never mind the point of the article.

Chris L. 11/11/03 04:46:22 PM EST

I agree with the previous comment. XP/Agile could make some developer and bussiness users hyper, over excited. They think it is a silver bullet to their problems. XP/Agile are like other methodology has its pros and cons. It has been proved somewhat sucessful in small scale, isolated application/prototype. It is not practical in large/enterprise level project. It is obvious that "daily refactory" just simple won''t work if there are lots of dependencies between different systems, which are controled under different departments or different outsourcing parties. Pair programming is useful when the satuiation fits and would not gain much under some other senarios....etc... The whole list deserve its own topic.
I am just curious that why not XP/Agile advocates address its short comings and in turns it can be prompted in the right way.......

Robert Cresswell 11/06/03 04:49:18 AM EST

This is an exploration of some programming techniques and I am sure its very usefull as teaching aid. It falls into the same trap that most of methods do (RUP,XP agile), by saying this is the way follow the way. I have been programming a very long time and I used methods like this and more exteme testing code fragments even. But the point is my methods are agile I customise my development techniques to suit the problem or the type of work I am addressing.
Please have pity every time you guys give hard and fast rules I have to deal with the fools who think its the one and only true way to work. Agile methods just says go back to the ways you always worked before the achedemics started telling you how to program.

@ThingsExpo Stories
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to...
Artificial intelligence, machine learning, neural networks. We’re in the midst of a wave of excitement around AI such as hasn’t been seen for a few decades. But those previous periods of inflated expectations led to troughs of disappointment. Will this time be different? Most likely. Applications of AI such as predictive analytics are already decreasing costs and improving reliability of industrial machinery. Furthermore, the funding and research going into AI now comes from a wide range of com...
In this presentation, Striim CTO and founder Steve Wilkes will discuss practical strategies for counteracting fraud and cyberattacks by leveraging real-time streaming analytics. In his session at @ThingsExpo, Steve Wilkes, Founder and Chief Technology Officer at Striim, will provide a detailed look into leveraging streaming data management to correlate events in real time, and identify potential breaches across IoT and non-IoT systems throughout the enterprise. Strategies for processing massive ...
SYS-CON Events announced today that GrapeUp, the leading provider of rapid product development at the speed of business, will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Grape Up is a software company, specialized in cloud native application development and professional services related to Cloud Foundry PaaS. With five expert teams that operate in various sectors of the market acr...
Internet of @ThingsExpo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with 21st Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The Internet of Things (IoT) is the most profound change in personal and enterprise IT since the creation of the Worldwide Web more than 20 years ago. All major researchers estimate there will be tens of billions devic...
SYS-CON Events announced today that Ayehu will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on October 31 - November 2, 2017 at the Santa Clara Convention Center in Santa Clara California. Ayehu provides IT Process Automation & Orchestration solutions for IT and Security professionals to identify and resolve critical incidents and enable rapid containment, eradication, and recovery from cyber security breaches. Ayehu provides customers greater control over IT infras...
SYS-CON Events announced today that MobiDev, a client-oriented software development company, will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. MobiDev is a software company that develops and delivers turn-key mobile apps, websites, web services, and complex software systems for startups and enterprises. Since 2009 it has grown from a small group of passionate engineers and business...
SYS-CON Events announced today that Cloud Academy named "Bronze Sponsor" of 21st International Cloud Expo which will take place October 31 - November 2, 2017 at the Santa Clara Convention Center in Santa Clara, CA. Cloud Academy is the industry’s most innovative, vendor-neutral cloud technology training platform. Cloud Academy provides continuous learning solutions for individuals and enterprise teams for Amazon Web Services, Microsoft Azure, Google Cloud Platform, and the most popular cloud com...
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to...
SYS-CON Events announced today that CA Technologies has been named "Platinum Sponsor" of SYS-CON's 21st International Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. CA Technologies helps customers succeed in a future where every business - from apparel to energy - is being rewritten by software. From planning to development to management to security, CA creates software that fuels transformation for companies in the applic...
We build IoT infrastructure products - when you have to integrate different devices, different systems and cloud you have to build an application to do that but we eliminate the need to build an application. Our products can integrate any device, any system, any cloud regardless of protocol," explained Peter Jung, Chief Product Officer at Pulzze Systems, in this SYS-CON.tv interview at @ThingsExpo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA
SYS-CON Events announced today that IBM has been named “Diamond Sponsor” of SYS-CON's 21st Cloud Expo, which will take place on October 31 through November 2nd 2017 at the Santa Clara Convention Center in Santa Clara, California.
Amazon started as an online bookseller 20 years ago. Since then, it has evolved into a technology juggernaut that has disrupted multiple markets and industries and touches many aspects of our lives. It is a relentless technology and business model innovator driving disruption throughout numerous ecosystems. Amazon’s AWS revenues alone are approaching $16B a year making it one of the largest IT companies in the world. With dominant offerings in Cloud, IoT, eCommerce, Big Data, AI, Digital Assista...
SYS-CON Events announced today that Enzu will exhibit at SYS-CON's 21st Int\ernational Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Enzu’s mission is to be the leading provider of enterprise cloud solutions worldwide. Enzu enables online businesses to use its IT infrastructure to their competitive advantage. By offering a suite of proven hosting and management services, Enzu wants companies to focus on the core of their ...
Multiple data types are pouring into IoT deployments. Data is coming in small packages as well as enormous files and data streams of many sizes. Widespread use of mobile devices adds to the total. In this power panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists looked at the tools and environments that are being put to use in IoT deployments, as well as the team skills a modern enterprise IT shop needs to keep things running, get a handle on all this data, and deliver...
In his session at @ThingsExpo, Eric Lachapelle, CEO of the Professional Evaluation and Certification Board (PECB), provided an overview of various initiatives to certify the security of connected devices and future trends in ensuring public trust of IoT. Eric Lachapelle is the Chief Executive Officer of the Professional Evaluation and Certification Board (PECB), an international certification body. His role is to help companies and individuals to achieve professional, accredited and worldwide re...
IoT solutions exploit operational data generated by Internet-connected smart “things” for the purpose of gaining operational insight and producing “better outcomes” (for example, create new business models, eliminate unscheduled maintenance, etc.). The explosive proliferation of IoT solutions will result in an exponential growth in the volume of IoT data, precipitating significant Information Governance issues: who owns the IoT data, what are the rights/duties of IoT solutions adopters towards t...
With the introduction of IoT and Smart Living in every aspect of our lives, one question has become relevant: What are the security implications? To answer this, first we have to look and explore the security models of the technologies that IoT is founded upon. In his session at @ThingsExpo, Nevi Kaja, a Research Engineer at Ford Motor Company, discussed some of the security challenges of the IoT infrastructure and related how these aspects impact Smart Living. The material was delivered interac...
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend 21st Cloud Expo October 31 - November 2, 2017, at the Santa Clara Convention Center, CA, and June 12-14, 2018, at the Javits Center in New York City, NY, and learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
No hype cycles or predictions of zillions of things here. IoT is big. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, Associate Partner at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He discussed the evaluation of communication standards and IoT messaging protocols, data analytics considerations, edge-to-cloud tec...