Welcome!

Java IoT Authors: Pat Romanski, Stackify Blog, Yeshim Deniz, Liz McMillan, Jason Bloomberg

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
To get the most out of their data, successful companies are not focusing on queries and data lakes, they are actively integrating analytics into their operations with a data-first application development approach. Real-time adjustments to improve revenues, reduce costs, or mitigate risk rely on applications that minimize latency on a variety of data sources. Jack Norris reviews best practices to show how companies develop, deploy, and dynamically update these applications and how this data-first...
Intelligent Automation is now one of the key business imperatives for CIOs and CISOs impacting all areas of business today. In his session at 21st Cloud Expo, Brian Boeggeman, VP Alliances & Partnerships at Ayehu, will talk about how business value is created and delivered through intelligent automation to today’s enterprises. The open ecosystem platform approach toward Intelligent Automation that Ayehu delivers to the market is core to enabling the creation of the self-driving enterprise.
In his session at @ThingsExpo, Dr. Robert Cohen, an economist and senior fellow at the Economic Strategy Institute, presented the findings of a series of six detailed case studies of how large corporations are implementing IoT. The session explored how IoT has improved their economic performance, had major impacts on business models and resulted in impressive ROIs. The companies covered span manufacturing and services firms. He also explored servicification, how manufacturing firms shift from se...
The question before companies today is not whether to become intelligent, it’s a question of how and how fast. The key is to adopt and deploy an intelligent application strategy while simultaneously preparing to scale that intelligence. In her session at 21st Cloud Expo, Sangeeta Chakraborty, Chief Customer Officer at Ayasdi, will provide a tactical framework to become a truly intelligent enterprise, including how to identify the right applications for AI, how to build a Center of Excellence to ...
SYS-CON Events announced today that Massive Networks will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Massive Networks mission is simple. To help your business operate seamlessly with fast, reliable, and secure internet and network solutions. Improve your customer's experience with outstanding connections to your cloud.
SYS-CON Events announced today that CAST Software will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. CAST was founded more than 25 years ago to make the invisible visible. Built around the idea that even the best analytics on the market still leave blind spots for technical teams looking to deliver better software and prevent outages, CAST provides the software intelligence that matter ...
Everything run by electricity will eventually be connected to the Internet. Get ahead of the Internet of Things revolution and join Akvelon expert and IoT industry leader, Sergey Grebnov, in his session at @ThingsExpo, for an educational dive into the world of managing your home, workplace and all the devices they contain with the power of machine-based AI and intelligent Bot services for a completely streamlined experience.
Because IoT devices are deployed in mission-critical environments more than ever before, it’s increasingly imperative they be truly smart. IoT sensors simply stockpiling data isn’t useful. IoT must be artificially and naturally intelligent in order to provide more value In his session at @ThingsExpo, John Crupi, Vice President and Engineering System Architect at Greenwave Systems, will discuss how IoT artificial intelligence (AI) can be carried out via edge analytics and machine learning techn...
SYS-CON Events announced today that Datera, that offers a radically new data management architecture, has been named "Exhibitor" of SYS-CON's 21st International Cloud Expo ®, which will take place on Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Datera is transforming the traditional datacenter model through modern cloud simplicity. The technology industry is at another major inflection point. The rise of mobile, the Internet of Things, data storage and Big...
In his session at @ThingsExpo, Arvind Radhakrishnen discussed how IoT offers new business models in banking and financial services organizations with the capability to revolutionize products, payments, channels, business processes and asset management built on strong architectural foundation. The following topics were covered: How IoT stands to impact various business parameters including customer experience, cost and risk management within BFS organizations.
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...
SYS-CON Events announced today that Pulzze Systems 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. Pulzze Systems Inc, provides the software product "The Interactor" that uniquely simplifies building IoT, Web and Smart Enterprise Solutions. It is a Silicon Valley startup funded by US government agencies, NSF and DHS to bring innovative solutions to market.
From 2013, NTT Communications has been providing cPaaS service, SkyWay. Its customer’s expectations for leveraging WebRTC technology are not only typical real-time communication use cases such as Web conference, remote education, but also IoT use cases such as remote camera monitoring, smart-glass, and robotic. Because of this, NTT Communications has numerous IoT business use-cases that its customers are developing on top of PaaS. WebRTC will lead IoT businesses to be more innovative and address...
WebRTC is great technology to build your own communication tools. It will be even more exciting experience it with advanced devices, such as a 360 Camera, 360 microphone, and a depth sensor camera. In his session at @ThingsExpo, Masashi Ganeko, a manager at INFOCOM Corporation, will introduce two experimental projects from his team and what they learned from them. "Shotoku Tamago" uses the robot audition software HARK to track speakers in 360 video of a remote party. "Virtual Teleport" uses a...
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be...
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...
SYS-CON Events announced today that Elastifile will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Elastifile Cloud File System (ECFS) is software-defined data infrastructure designed for seamless and efficient management of dynamic workloads across heterogeneous environments. Elastifile provides the architecture needed to optimize your hybrid cloud environment, by facilitating efficient...
SYS-CON Events announced today that Golden Gate University will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Since 1901, non-profit Golden Gate University (GGU) has been helping adults achieve their professional goals by providing high quality, practice-based undergraduate and graduate educational programs in law, taxation, business and related professions. Many of its courses are taug...
Recently, WebRTC has a lot of eyes from market. The use cases of WebRTC are expanding - video chat, online education, online health care etc. Not only for human-to-human communication, but also IoT use cases such as machine to human use cases can be seen recently. One of the typical use-case is remote camera monitoring. With WebRTC, people can have interoperability and flexibility for deploying monitoring service. However, the benefit of WebRTC for IoT is not only its convenience and interopera...
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be...