Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Test-Driven JavaScript Development

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Programming 55

eldavojohn writes "Test-Driven JavaScript Development by Christian Johansen is a book that thoroughly guides the user through some of the more advanced aspects of the JavaScript language and into Test-Driven Development (TDD). Throughout it, Johansen introduces great methods and utilities like libraries to accomplish all aspects of TDD in JavaScript. The book begins with Johansen demonstrating and teaching the reader some of the more advanced aspects of JavaScript to ensure that the following lessons in TDD are well understood. The best part of the book is in the last half where Johansen builds a chat client and server completely out of JavaScript using TDD right before the readers' eyes." Keep reading for the rest of eldavojohn's review.First off the audience for this book are JavaScript developers interested in TDD. More specifically, I would identify the audience being the poor developers that have slaved over JavaScript for endless hours only to find out that there are 'discrepancies' in how their JavaScript functions in one browser versus another (or even across versions of the same browser). If you've ever came into work one day to learn that the latest version of Internet Explorer or Mozilla Firefox now throws errors from the deep recesses of your code and you have absolutely no idea where to start, then this book may be an item of interest to you. After all, wouldn't it be great to pull up the new browser and simply watch all your tests complete code coverage with glaring red results listing specific problematic locations?

Secondly, I'd like to establish that I'm writing this review with two key assumptions. The first assumption is that JavaScript is not in and of itself evil. You might hate JavaScript (as did I at one time) but it's a very flexible and enjoyable language when you're not battling some crazy 'feature' that a particular JavaScript engine exhibits or some issue with the dreaded Document Object Model (DOM). The second assumption is that TDD is a net positive when done correctly. To some, it may be a hard sell and the author of the book is no blind preacher. TDD has its pitfalls and the book adequately notes these claiming that TDD can actually work against you if used improperly. Feel free to wage wars in the comments debating whether or not the average JavaScript monkey is capable of avoiding pitfalls and learning to write good unit tests — I'm not getting sidetracked in this review on those topics.

This book is divided into four parts. The first part of the book gives you a slight taste of testing right off the bat in chapter one (Automated Testing). Johansen starts by showing a strftime function written in JavaScript and demonstrates briefly the very clumsy standard method of testing the method in a browser. From there he introduces Assertions, Setup, Teardown and Integration Tests. What I particularly enjoyed about this book is that these key components are not forgotten after introducing them, Johansen constantly nods to the reader when duplicate code could be moved to Setup or Teardown.

Chapter two is devoted to 'turning development upside-down.' This chapter analyzes the mentality of writing a test, running the test, watching it fail, making the test pass and then refactoring to remove duplication (if necessary). Johansen stresses and restresses throughout the book that the simplest solution should be added to pass the test. Fight the urge to keep coding when you are sure what comes next and just make sure you have unit tests for that new code. The third chapter runs through many test frameworks in JavaScript and settles in on JsTestDriver weighing the pros and cons of each option. Lastly, it is demonstrated how to use JsTestDriver both inside Eclipse and from the command line (something I deeply appreciated). Chapter Four expands on this by proposing learning tests which are tests that you keep around to try out on new browsers to investigate what you depend on. I'm not entirely sold on this practice but this chapter is definitely worth the look at performance testing it provides in a few of the more complete aforementioned frameworks.

The next 145 pages are devoted to the JavaScript language itself. The reader will find out in later chapters why this was necessary but this second part felt too long and left me starving for TDD. There's a ton of great knowledge in these chapters and Johansen demonstrates an impressive display in his understanding of ECMAScript standards (all versions thereof) and all the JavaScript engines that implement them. In the following four chapters, the reader is shown the ins and outs of scope, functions, this, closures, anonymous functions, bindings, currying, namespaces, memorization, prototypical inheritance, tons of tricks with properties, mixins, strict mode and even the neat features of tddjs and JSON. What I was most impressed with in this chapter was how much care Johansen took with noting performance pitfalls in all of the above. Example: "closures in loops are generally a performance issue waiting to happen" and on for-in arrays he says "the problem illustrated above can be worked around, as we will see shortly, but not without trading off performance." Johansen seems tireless in enumerating the multitude of ways to accomplish something in JavaScript only to dissect each method critically. If you skip these sections, at least look at 6.1.3 as the bind() implementation developed there becomes critical throughout much of the book's code.

Chapter nine provides yet more dos and do nots in JavaScript with a tabbed panel example that demonstrates precisely what obtrusive JavaScript is and why it is labeled as such. Chapter ten is definitely not to be skipped over as it provides feature detection methods (specifically with regard to functions and properties) that are seen in later code snippets. Part two is devoid of any TDD yet rich in demonstrating the power of JavaScript. This is where the book loses a point for me as this seemed too long and a lot of these lessons — though informative — really seemed like they belonged in another book on the JavaScript language itself. I constantly wondered when I would start to see TDD but to a less experienced developer, these chapters are quite enlightening.

In the third part, we finally get to some TDD in which an Observer Pattern (pub/sub) is designed using tests with incremental improvements in true TDD fashion. Most importantly to the audience, we encounter our first browser inconsistencies that are tackled using TDD. This chapter illustrates how to make your first tdd.js project using the book's code and build your first tests followed up with the isolation of the code into setup and teardown functions. Rinse, wash, repeat for adding observers, checking for observers and notifying observers (all key functionality in the common observer paradigm). This is a great pragmatic example for TDD and the chapter wraps up with error checking and a new way to build a constructor. As we do this, we have to make changes to the tests and Johansen illustrates another critical part of TDD: fixing the tests after you've improved your code.

The twelfth chapter takes our Ajax friend the XMLHttpRequest object and gives it the same treatment as above. Of course, you might know it as the Msxm12.XMLHTTP.6.0 object or a variety of names so this is where our browser differences are exposed. On top of that, we're exposed to stubbing in order to test such an object. The author explores three different ways of stubbing it while building tests for GET requests. After building helpers to successfully stub this, we move on to POST, finally send data in a test and then pay attention to the testing of headers. Personally these two chapters were some of the best in the book and illustrated well a common method of utilizing TDD and stubbing to build up functional JavaScript.

Chapter thirteen builds on the previous chapter by examining polling data in JavaScript and how we might keep open a constant stream of data. Before jumping to the solution, the author investigates strategies like polling intervals and long polling which have their downfalls. We eventually come to the Comet client (which uses JSON objects) and build up our test cases that support our development of our new streaming data client. One important aspect brought up is the trick of using the Clock object to fake time. This was completely new to me and very interesting in simulating time with tick() to quickly fake and test expected lengths of time.

Chapter fourteen was definitely outside of my comfort zone. JavaScript on the server-side? Blasphemy! Johansen begins to bring together the prior elements to form a fully functional chat server all in JavaScript through TDD. In this chapter the reader is introduced to node.js and a custom version of Nodeunit the author modified to make a little more like JsTestDriver. The controller emerges through the TDD cycles. Responses to POST, adding messages, the domain model and even storage of data are given test cases to insure we are testing feature after tiny feature. Toward the end of the chapter, an interesting problem arises with our asynchronous interface. In testing it, how do we know what will result from a nested callback? Johansen introduces the concept of a Promise which is a placeholder that eventually provides a value. Instead of accepting a callback, the asynchronous method returns a promise object which is eventually fulfilled. We can now test adding messages in asynchronous manner to our chat room. The chapter builds on the chat server to passable functionality — all through TDD.

Chapter fifteen concentrates on building the chat client to the above server and in doing so provides the reader with TDD in regards to DOM manipulation and event handling. This chapter finally covers some of the more common problematic aspects of client-side JavaScript. Again, this chapter yielded many tricks that were new to me in TDD. JsTestDriver actually includes two ways to include HTML in a test and Johansen shows how to manipulate the user form on a page in order to test it automatically. The client is developed through TDD and node-paperboy is called in to serve up static files through http with Node.js. The message list displayed in the client is developed through TDD and then the same process used on the user form is done with the message form submission. The author brings in some basic CSS, Juicer and YUI Compressor to reduce all our work down into a 14kB js file containing an entire chat client. With gzip enabled it downloads at about 5kB. Potent stuff.

I was sad that more pages weren't spent on the final section. Chapter sixteen further expounds upon mocking, spies and stubbing. It lists different strategies and how to inject trouble into your code by creating stubs that blow up on purpose during testing. And we get a sort of abbreviated dose of Sinon, a mocking and stubbing library for JavaScript. The author repeats a few test cases from chapter eleven and moves on to mocking. Mocking is mentioned throughout the book but is passed over due to the amount of work required to manually mock something. The chapter ends with the author saying 'it depends' on whether you should use stubbing or mocks but it's pretty clear the author provides stubbing as he enumerates the pros and cons of each.

Chapter seventeen provides some pretty universal rules of thumb to employ when using TDD. From the obvious revealing intent by clear naming to strategies for isolating behavior, it's got good advice for succeeding with TDD. This advice aims to improve readability, generate true unit tests that stay at the unit level and avoid buggy tests. It's worth repeating that he gives a list of 'attacks' for finding deficiencies in tests: "Flip the value of the boolean expressions, remove return values, misspell or null variables and function arguments, introduce off-by-one errors in loops, mutate the value of internal variables." Introduce one deficiency and run the tests. Make sure they break when and where you would expect them to or your testing isn't as hardened as you might expect. Lastly the author recommends using JsLint (like lint for C).

There's a lot of information in this book but I think that the final examples were actually too interesting for my tastes. Often I grapple with the mundane and annoying parts of client side DOM — nothing on the server side. While this might change at some point in the future, I couldn't help but feel that the book would have been better with additional examples of more common problems than a chat client in JavaScript. I was certainly impressed with this example and it will hold the readers' attention much more than what I desire so I feel comfortable recommending this book with a 9/10 to anyone suffering from browser inconsistencies or looking to do TDD in JavaScript.

You can purchase Test-Driven JavaScript Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

55 comments

Sorry! There are no comments related to the filter you selected.

Letting it all out (5, Interesting)

Anrego (830717) | more than 3 years ago | (#35642780)

I know I’m out of the web dev loop, but as I recall, in most cases the web mantra seems to be to crank it out as quick as possible before it’s obsolete. The exposure I’ve had (which admittedly is a small sampling) leads me to believe that even basic core principles of traditional software development are thrown out the window in a mad dash to get something that “looks right”.

Certainly the tools that have become the most popular around web dev would spell this out. Javascript, PHP, python, etc. Weakly types languages with loose structure, built in shortcuts, and lots of automagic. The whole concept of prototype based coding is to me just another example of rapid development trumping solid coding.

And I’ve heard the “compensate with better QA” or the even more ludicrous “just hire people who never make mistakes” arguments. I’ll take my programming with strong typing and lots of built in idiot-proofing please, and I’m not afraid to admit that even with years of dev experience, I still make the occasional bone headed mistake and I figure the more chances it gets caught, the better.

I think it’s good that _someone_ is trying to mix solid software development with web whimsy, but I don’t see it catching on, even in places where it really should!

I’d like to note, that while this may start a flame war (or get harmlessly modded down to oblivion), this really wasn’t my intention.

I’d also like to note, that I dislike TDD in general (yeah, I know, another flame war)! In my experience, most bugs I find are from running through some kind of manual procedure and noticing something ”odd” that an automated system wouldn’t have picked up. I imagine in web design, where the end result is mainly visual, this would be even more common. Sure, the table has the right values but they are all cut off and too tiny to read.

I do like broad, interface level unit testing (if you can call it that) to test that inputs into the system as a whole result in appropriate output, as these kind of requirements rarely change but individually testing classes just adds extra work, extra bulk when making changes, and never seems to find anything! I have run into this so many times, where someone comes up with a really great way to refractor some code, only to find out that while the code change would be trivial, updating 50 unit tests wouldn’t so it doesn’t happen.

And I can come up with much better and more productive ways to document behaviour and coordinate between developers (written documents, java style interface classes/etc) than a bunch of cumbersome unit tests.

Re:Letting it all out (-1)

Anonymous Coward | more than 3 years ago | (#35642876)

I know I’m out of the web dev loop, ...

You should have stopped there.

Re:Letting it all out (2)

unity100 (970058) | more than 3 years ago | (#35642920)

I know I’m out of the web dev loop, but as I recall, in most cases the web mantra seems to be to crank it out as quick as possible before it’s obsolete. The exposure I’ve had (which admittedly is a small sampling) leads me to believe that even basic core principles of traditional software development are thrown out the window in a mad dash to get something that “looks right”.

its not web development that is in a perpetual 'mad dash' to get things out - it was the 'traditional software development' was a relic of ancient times when software as well as the hardware it runs on was mainly used by big megacorporations. back then users were these, and their demands were big, persistent and what they got the software developers to build remained as standard for decades. there are still a lot of important financial institutions which are running on as400 for example.

so, software was treated as if it was something for a big, slow, years-long engineering project, like bridges or car prototypes.

that approach was wrong from the start. that would be needed only for infrastructures and operating systems, platforms the software was to run on, like linux.

if we should make a car analogy, the 'software engineering' approach was necessary for designing the car infrastructure - ie hybrid/gasoline or electric, the basic principles of a car type and so on.

software, was to be used on the car itself. like its car stereo, air condition, seat covers and so on.

but, the traditional, obsolete understanding of software, tended to take ALL of them as 'big engineering' projects which were to be designed and built in years' time.

but, the car chassis and type should have been independent from the car stereo you put into the car, the seat covers and so on. the latter require more customization, more choice, speedier design and production cycles. noone can wait for a car company to come up with a car bundled with a different stereo to be able to use a different stereo in their car.

and then came the web. real people, end users came into the equation. they demanded custom, easy, fast stuff. and this has changed the software production forever. noone can wait for years to use something. a lot can happen in the duration of a year, and a lot can go without being done.

Re:Letting it all out (3, Interesting)

Anrego (830717) | more than 3 years ago | (#35643110)

I kind of lump TDD in with traditional older-style thinking.

I admit I tend to have a kind of waterfall mentality. You spend months documenting _exactly_ what is needed, months designing the thing down to the tiny component parts, then proceed to basically paraphrase the design into code form. Slow, inflexible, inefficient ... and everything is moving away from it.

TDD seems to be a relic of this approach. It would assume you have that first part, a very detailed list of everything you need, up front, before implementation. I've never understood how this is moving forward. To me we should be moving towards approaches that let us change requirements on the fly without it being a massive undertaking. Agile types may feel free to educate me as to why I'm an idiot here! To me TDD binds hands just as effectively as the miles of design and requirement docs did, and this seems like a bad thing.

As for the bulk of your comment, I think we need a middle ground. Less hectic and "seat of your pants" ish, but not process overkill. The old "good, cheap, fast - pick 2" argument... but we need a little bit more "good".

Re:Letting it all out (2)

smoothnorman (1670542) | more than 3 years ago | (#35643362)

You guys are all ready for the web-dev-dustbin (or WDD)! TDD is utterly yesterday/old-school. TLA is the the only way to go. I've been deep involved in over 6.02x10^23 web-dev action XP teams divided into AUP units of Pair Programming for Kaizen RDP syndication of Direct Market facilitated Six Sigma productions. TLA is to OO what TDD was once to TRIZ. If you aren't on the TLA bandwagon you might as well be using VB to take aim at BDUF, DRY, JAD even TSP! OMG guys get a CLU and get on TLA!

Re:Letting it all out (1)

unity100 (970058) | more than 3 years ago | (#35643392)

hahaha ! you people are so shindigbaabs (SCB). i would prefer gaguli approach (GAGI) myself ...

Re:Letting it all out (1)

Javaman59 (524434) | more than 3 years ago | (#35645672)

I've been deep involved in over 6.02x10^23 web-dev action XP teams

Thank you, old man, we appreciate you sharing some of your experience. We really do.

Re:Letting it all out (2)

khr (708262) | more than 3 years ago | (#35643434)

To me TDD binds hands just as effectively as the miles of design and requirement docs did

In some ways yes, and in some ways, no...

Unlike miles of design and requirements docs, the test code is more "alive" and if the TDD approach is followed closely, stays in sync with the code. The tests also tell you as you're modifying the code what other changes need to go with the ones already know about. Developers are more likely to maintain the test code than the documentation, which is more likely to be "I'll update it later, after the deadline."

My previous two projects were a waterfall one and an Extreme Programming one. The difference between them was like night and day... In the first it was weeks or months of functional specs, every static screen shot pixel perfect or the boss wouldn't even look at the rest, only to spend weeks or months writing the code and have the boss say "this is crap! and you're idiots!". The second one everyone expected things to change as we developed and as the analysts worked with customers and the XP approach really kept us on top of it, with all the TDD tests helping us be more thorough as we modified existing code and wrote new code.

Sure, it was more than just waterfall vs. agile, the attitude of the project owners made a huge difference, and a small team weighed with more experienced developers overall did better than a gigantic team with mostly junior ones...

Re:Letting it all out (3, Interesting)

slim (1652) | more than 3 years ago | (#35643942)

TDD seems to be a relic of this approach. It would assume you have that first part, a very detailed list of everything you need, up front, before implementation.

You seem to have a misapprehension of TDD. TDD is very agile; you write tests as a way to explore the problem space. Tests can be amended, and even deleted as you go along. It's a tight loop consisting of:

- while not finished {
    - Invent a test, write it -- it is likely to not compile, as it will reference types and methods that don't exist
    - Write just enough code for the test to compile - skeleton classes with methods that return null
    - Code until all your tests pass
    - refactor to remove any duplicate code, re-running the test suite between each refactoring
- }

It is *not* a matter of writing all your tests upfront. It's more like "Hmm, my game is going to need a scoreboard class, and when I construct it, the score should be zero, so I'll write a test for that now."

Having done TDD (0)

Anonymous Coward | more than 3 years ago | (#35648718)

I'm still quite skeptical. It seems the overwhelming majority of the time spent on TDD is spent writing test cases which will never fail. There's a reason why I don't write a test case for a starting score of zero - it's because if I forget to initialize the score variable:

  1. I'm going to notice it the first time I run the program, and
  2. It will take no more than 30 seconds to fix

The problem with TDD is that you write far too many tests for trivial mistakes, and far too few for the more esoteric ones, like race and deadlock conditions. The art of getting a project done on time is figuring out what *kinds* of mistakes programmers are likely to make, and writing tests for *those conditions*. It makes little point to spent 30 minutes writing a test case for something the compiler will complain about anyway.

There is a certain wisdom in knowing that 90 percent of the bugs in code are caught with less than 5% of the test cases. Knowing which 5% those are is much more valuable than following some development mantra to the T.

Re:Letting it all out (0)

Anonymous Coward | more than 3 years ago | (#35650312)

TDD scales very poorly with complexity. The resulting aggregate of "it seemed like a good idea at the time" and "maybe this will solve the problem" often needs "refactoring" (i.e., rewriting 25+% of the code base) to iron out problems that could have easily been caught with a proper analysis,

Re:Letting it all out (0)

Anonymous Coward | more than 3 years ago | (#35649078)

I think one of the reasons a lot of people don't like or don't "get" TDD (or at least realize benefits) is the language it's being used with. I seriously invite anyone who is a TDD skeptic to watch a seasoned Smalltalk developer do TDD. You can literally program in the debugger and do things like have unit tests that run as you type the associated implementation. It's something that is uniquely Smalltalk really. It's not hard after you see why it was/is so popular in that world.

I write code in lots of languages, and I frankly find TDD in Java and C# pretty asinine. I still do it because it does help me find bugs, but I feel like someone cut off my legs and hands compared to when I work in Smalltalk. You can throw all the refactoring tools and nifty IDE features, but if your programming environment is not something close to an OS like most Smalltalk dialects, you really miss out. I think the people who are critical of TDD have never actually seen what it can really do with the proper tools and techniques. J

avaScript is a somewhat better fit, but still lacks an efficient dev mechanism. A huge reason why I feel it works in Smalltalk is you don't have to break your flow at all. You write a test, implementation, and run a test all in the same place. Hell, you can do it all in the same window, stacks of windows, or even in your own custom UI. I don't see any other environment that can compete on this level.

Re:Letting it all out (1)

gl4ss (559668) | more than 3 years ago | (#35650068)

tdd is an extra step introduced to waterfall, as a fix for the low quality output from waterfall process. it didn't work, so things are moving to honest agile. around here universities are to blame, also it has to do with the will to use more people per project, as if that magically would've fixed things, giving everyone a well defined role. too bad defining that role before knowing what needs to be done is a disaster.

Re:Letting it all out (1)

sartin (238198) | more than 3 years ago | (#35654284)

It would assume you have that first part, a very detailed list of everything you need, up front, before implementation.

There's the source of your misunderstanding about TDD. TDD assumes you have a test before you develop, not all of them. I had this problem with a manager with a waterfall background once. She kept asking when the tests would be "done" and I kept telling her "when we release" (okay, a little before release, but not much). When I do TDD the alternation between test writing and code writing is very high frequency - generally multiple times per day or even hour. I start with working code. I have a need to implement a feature (or fix a bug). I write a test. I write code to make the test work. Rinse. Repeat.

The tests driving the design don't have to be unit tests. I've developed TDD using acceptance tests as the driver. I've even (gasp!) used manual tests as the driver. I've even thrown out huge chunks of tests when plans changed, though more often I find that the base of tests helps me deal with the change rather than hindering me as some seem to fear.

Personally, I find TDD gets me to writing code that has fewer bugs (this part I've measured on some projects) and is easier to change (this is totally subjective) than the other approaches I've used, which have ranged from traditional waterfall (design everything in advance before coding) to just writing code as fast as I could spew it from my brain to the keyboard.

My gut is that TDD is short-term slower than just producing code as fast as I can think, but long-term pays back in maintainability. The challenge is figuring out when the net benefit goes positive. I actually used TDD for a "one off" recently (because I was rusty in the language and wanted to refresh my skills) and later found an opportunity to use the code again with slight modifications thanks to having the tests; that's more a benefit of the T rather than the whole TDD though.

YMMV.

Re:Letting it all out (0)

Anonymous Coward | more than 3 years ago | (#35656592)

Jesus Christ, learn to use your SHIFT key. Who do you think you are, e. e. cummings?

Re:Letting it all out (1)

by (1706743) (1706744) | more than 3 years ago | (#35642998)

Additionally, since JS is historically predominantly client-side, robust server-side validation should always be used. So in that sense, it's somewhat less important to have thorough testing -- a shopping cart which says the total for your new flatscreen is $0.00 and then fails when you go to pay for it is a much better problem to have than a system which displays the total correctly, but changes $0.00...

Of course, the best solution is to have neither issue =)

Python is strongly typed (0)

Anonymous Coward | more than 3 years ago | (#35643086)

Unlike JS and PHP, Python is a strongly typed language.

Re:Python is strongly typed (1)

Anrego (830717) | more than 3 years ago | (#35643168)

I admit I know very little python, but as I understand it, while it does track the variable types for you... it doesn't do much to prevent you from using the wrong type in the wrong spot (enter automagic to try and make it work for you).

Obviously this is a step up from no typing at all, and the bulk of my comment was more aimed at JS and PHP... but I still prefer rigid typing that won't even let you use a bool or char as an int, even if that's how it's stored (if it's what you wanted to do.. cast it..).

Re:Python is strongly typed (1)

by (1706743) (1706744) | more than 3 years ago | (#35643236)

Sounds like you're (aspersions) other_languages.

Oh, sometimes I crack myself up.

Re:Python is strongly typed (2)

CannonballHead (842625) | more than 3 years ago | (#35643428)

it doesn't do much to prevent you from using the wrong type in the wrong spot (enter automagic to try and make it work for you).

In my experience:
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 'hello'
>>> print a + 2
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot concatenate 'str' and 'int' objects

... and ...
>>> a = 2
>>> a = a + 'hi there'
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>> print a.find('string')
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'int' object has no attribute 'find'

Ok, so it is more of an attribute and operand issue, but it doesn't do a whole lot of typecasting automagically for you. You have to use something like str(anIntegerVariable) or int(aStringVariable)... and while integers have string representations, all strings do not have integer representations:
>>> print int('asdf')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'asdf'

Re:Python is strongly typed (1)

radtea (464814) | more than 3 years ago | (#35655742)

but I still prefer rigid typing that won't even let you use a bool or char as an int, even if that's how it's stored (if it's what you wanted to do.. cast it..).

What Python has a type system that's fairly strong, but it also has an oddball way of name binding that means a name takes its type from the last thing assigned to it. The object the name refers to still has a strong type, but the name can be recycled to refer to an object of different type.

C++ is actually drifting in this direction, with the absolutely wonderful "auto" keyword in C++0x, which flags a name so the compiler can assign its type based on the type of its initializer. If Python names could be declared of immutable type it would achieve the same functionality from the opposite direction.

Likewise, C++ prototypes were intended to give some of the "duck typing" flavour of Python, because there are times when type doesn't matter but interface does. I am not an unequivocal fan of duck typing because there are trivil cases in the language itself when the same operator on two different types has completely different semantics: strings and lists both support [], but the meaning of a character within a string is completely different from the meaning of an object within a container. The coupling between characters and the strings they are part of is is high, while the coupling between containers and the things they contain is low.

I haven't used Python 3 at all, but have found like so many others that once I got over the "OMG it's full of whitespace!" thing Python is an enormously powerful and fun language, and an excellent language for teaching software development.

Javascript is ugly but usable. PHP is astonishingly ugly and barely usable, and having spent the last week or two working on some Wordpress stuff in PHP I have to say it is hands down the most ridiculous language I have ever had the misfortune of using. I have no idea why anyone would prefer it to perl or Python on the server. My only guess is that it is sold to people who know nothing about software design as "you too can write amazing Web 2.0 applications!" Certainly if all the examples and tutorials out there are any indication there are no competent developers or designers working in PHP.

Re:Python is strongly typed (1)

Raenex (947668) | more than 3 years ago | (#35659508)

PHP is astonishingly ugly and barely usable, and having spent the last week or two working on some Wordpress stuff in PHP I have to say it is hands down the most ridiculous language I have ever had the misfortune of using. I have no idea why anyone would prefer it to perl or Python on the server. My only guess is that it is sold to people who know nothing about software design as "you too can write amazing Web 2.0 applications!"

Pretty much, but PHP gained popularity well before the "Web 2.0" meme. It was basically Perl revamped with a hard focus on embedding code and database access into web pages. So yeah, it was sold as an easy way to throw together some web pages that barfed up some info from a database.

It's kind of like how HTML is a shitty markup language for serious development, yet was easy for amateurs to work with so it won. Worse is better, and all that.

Re:Letting it all out (2)

trollertron3000 (1940942) | more than 3 years ago | (#35643206)

I understand your criticism of prototype languages, but Python is not one of them. Python is a strongly typed language. [python.org]

Re:Letting it all out (2)

Anrego (830717) | more than 3 years ago | (#35643246)

Yeah, in retrospect python doesn't really belong on that list.

My apologies to the python community :(

Re:Letting it all out (1)

CannonballHead (842625) | more than 3 years ago | (#35643444)

Doh, I just responded to it, too. Ignore my code examples ... hehe :)

Re:Letting it all out (2)

trollertron3000 (1940942) | more than 3 years ago | (#35644370)

No worries. Python has just as many ways to fuck up your day.

Re:Letting it all out (0)

Anonymous Coward | more than 3 years ago | (#35646598)

Of course while Python may be strongly typed, it's not staticly typed, which means you don't get the compile-time sanity check or the same level of help from the IDE in identifying possible errors. So your original point about web developers using tools that give them more rope to hang themselves with is still true with respect to Python.

Re:Letting it all out (3, Insightful)

dkleinsc (563838) | more than 3 years ago | (#35643312)

You've made a lot of mistakes here.

1. Python should not be lumped in with PHP. I've worked professionally in both languages, and in PHP it's far easier to write terrible code than it is to write good code, whereas in Python it's the other way around.

2. The value of automated tests is to prove that your code does what you think it's supposed to do. Now, you're correct that sometimes doing what you think is right is still wrong, but it picks up a surprisingly large number of bugs.

3. The value of TDD is that you are encouraged to have code that does what it's supposed to do, but nothing more than that. That's because you define the expected behavior (your test case) first, then ensure your code can do that.

4. The name for broad, interface level testing is an "end-to-end" test. This is a good thing to do, but it's no substitute for testing smaller components. Consider, for instance, 7 layers where each layer can do 2 different things based on the input. If you test each layer plus 2 end-to-end sanity tests, that's 16 tests. If you test only the whole thing, that's at least 128 tests. Because 128 tests is far more work than 16 tests, it typically doesn't happen at all, leading to bugs.

Re:Letting it all out (1)

Anrego (830717) | more than 3 years ago | (#35643480)

The name for broad, interface level testing is an "end-to-end" test.

Thanks! Seriously, I have always wondered what this was actually called!

Python should not be lumped in with PHP.

Agreed, in retrospect it shouldn't really be on that list. My apologies to the python community :(

The value of TDD is that you are encouraged to have code that does what it's supposed to do, but nothing more than that. That's because you define the expected behavior (your test case) first, then ensure your code can do that.

I see this approach working, but don't really like it. If people went _directly_ to unit tests, maybe, but in all implementations I've seen, people have to do some design work first. In this instance, it's always seemed to me that the unit test is a layer between design and code. A layer that has to be updated if any refactoring happens during implementation. I'd personally rather go right to code, and validate with traditional testing. As said though, I do understand this opinion and think it's valid.

Because 128 tests is far more work than 16 tests, it typically doesn't happen at all, leading to bugs.

I guess it depends on how much variation is needed to test each path. In the case of systems with very few inputs/outputs... it can be trivial to build a test harness that feeds it a pre-set list of inputs to test the various paths/branches. In some cases, basic logic can even generate these lists for you. In a UI driven app, I'd prefer manual procedures do to the "hey, that looks odd" factor... but I admit these arn't as thorough. I'd also note that in large systems with reasonably seperate components.. these components can be tested in the manner I talked about. I'm just generally against going down to the individual class level.

Re:Letting it all out (1)

gillbates (106458) | more than 3 years ago | (#35649030)

The value of TDD is that you are encouraged to have code that does what it's supposed to do, but nothing more than that.

No, that's the downfall of TDD - nothing you write is reusable, and any change of requirements invalidates both the test and the code tested.

I've worked in places where this was almost a religious practice. Instead of building libraries of general-purpose routines, they reinvented the wheel, every single time. They had a large amount of similar code which behaved in subtly different ways, was mutually incompatible, and couldn't be reused because it implemented the requirement, and nothing more than the requirement.

I'd find code akin to a string comparison which stops at 16 characters, because the source field will never be larger than that. With its own unit test. And another which compared unicode - with its unit test as well. And another which called stricmp on a 4 byte field, because - well, you guessed it - the field could never be more than 4 characters. And another which did the same test by casting the value in a 4 byte character array to an int, and comparing it against another 4 byte field cast to an int, nevermind the fact that it wasn't portable across architectures with differing byte orders.

OTOH, I've also worked at sweatshops where almost none of the code was documented, was written under constant time pressure, and yet was very readable and understandable because the author used meaningful variable names and architected it in such a manner that it made sense to a programmer, not the business user. Oh, and we had a lower defect rate per kloc than those using TDD, in spite of the fact that we didn't write any tests at all.

A Few Responses (4, Interesting)

eldavojohn (898314) | more than 3 years ago | (#35643368)

I know I’m out of the web dev loop, but as I recall, in most cases the web mantra seems to be to crank it out as quick as possible before it’s obsolete.

I think ECMAScript standards are here to stay for quite a while. I wouldn't worry about too much changing between 5 and 6. This book actually considers all versions of ECMAScript and ES5 was standardized in 2009 [wikipedia.org] , 10 years after the last standardized version. While it takes a while for JavaScript engines to catch up on implementing those standards, I wouldn't spin this sort of stuff as "crank it out quick."

The exposure I’ve had (which admittedly is a small sampling) leads me to believe that even basic core principles of traditional software development are thrown out the window in a mad dash to get something that “looks right”.

Certainly the tools that have become the most popular around web dev would spell this out. Javascript, PHP, python, etc. Weakly types languages with loose structure, built in shortcuts, and lots of automagic. The whole concept of prototype based coding is to me just another example of rapid development trumping solid coding.

I believe this is a false dichotomy that may have been true years ago. Once you see the maturity level of some JavaScript projects that companies like Google are working on, JavaScript doesn't have to be the slap dash crap you are speaking of. It just becomes clear that the language produces products equivalent to how much time is put into it. Here's one of many good counterexamples to your rule [google.com] . I am interested though: how do you define "solid coding?" That sounds like an ambiguous phrased designed to pick and choose language features as the user personally desires. The recent removal of OO programming from CMU's curriculum might point out how yesterday's mentality goes out of style and comes back in two decades later.

And I’ve heard the “compensate with better QA” or the even more ludicrous “just hire people who never make mistakes” arguments. I’ll take my programming with strong typing and lots of built in idiot-proofing please, and I’m not afraid to admit that even with years of dev experience, I still make the occasional bone headed mistake and I figure the more chances it gets caught, the better.

I think it’s good that _someone_ is trying to mix solid software development with web whimsy, but I don’t see it catching on, even in places where it really should!

Ima let you finish. But I just want to say that that is a totally respectable position. Me, personally, I recognize that I have a huge diverse toolbox full of all sorts of tools. Some better for jobs inside the browser, some better for servers and some better for embedded systems. But I would ask you to consider that it's going to be a while before any of these tools to be your silver bullet.

I’d like to note, that while this may start a flame war (or get harmlessly modded down to oblivion), this really wasn’t my intention.

I’d also like to note, that I dislike TDD in general (yeah, I know, another flame war)! In my experience, most bugs I find are from running through some kind of manual procedure and noticing something ”odd” that an automated system wouldn’t have picked up. I imagine in web design, where the end result is mainly visual, this would be even more common. Sure, the table has the right values but they are all cut off and too tiny to read.

There are certainly problems with rendering and layouts being difficult to automatically test. But there are a lot of tools out there (like firebug) that help you pin down what is going wrong in certain browsers. While the book doesn't delve deeply into it, it's something that is easier to deal with than, say, a weird JavaScript error appearing in IE resulting in some strange session or DOM value setting. This has happened to me many many times. Is it getting more infrequent with more responsible browser makers? You bet. But if you're coding for a Fortune 500 Company and you've gotten your ass chewed for JavaScript code that you wrote that one day didn't work in the latest IE or IE6 you might value the extra coding.

I do like broad, interface level unit testing (if you can call it that) to test that inputs into the system as a whole result in appropriate output, as these kind of requirements rarely change but individually testing classes just adds extra work, extra bulk when making changes, and never seems to find anything! I have run into this so many times, where someone comes up with a really great way to refractor some code, only to find out that while the code change would be trivial, updating 50 unit tests wouldn’t so it doesn’t happen.

And this is the birth of "spaghetti code." Where fifty people have touched this code and refactored it with little to no documentation. And now you've inherited it and everywhere there are dragons. I might argue that if you're refactoring a piece of code and then you have to change fifty unit tests all in the same manner, it might be possible to extract that code into a setup, teardown or helper method/function so that you just have to change it a few times. I'm not saying this never happens but when it does, it's often a matter of search/replace. A counterpoint is that I've added a feature to a piece of code and a bunch of tests have turned red. In making them "green" again, I found some problems with the new code and learned a lot about the boundary cases those before me had envisioned. There are good things that come from your nightmare scenario.

And I can come up with much better and more productive ways to document behaviour and coordinate between developers (written documents, java style interface classes/etc) than a bunch of cumbersome unit tests.

This is bizarre. I must be a different kind of developer. As someone who loves to write code and would rather be punched in the face than produce documents like powerpoints and README files, I cannot fathom what expensive "productivity" suite you are at the mercy of. But I know I don't want any part of that stuff. Just let me code, let me write unit tests for documentation and let those after me read the unit tests and understand what parameters I meant that code to fit.

Re:A Few Responses (1)

radtea (464814) | more than 3 years ago | (#35656064)

I am interested though: how do you define "solid coding?"

Start with Steve McConnell's book "Writing Solid Code", which of course you have read, right? Because good programming practice never goes out of style.

I see the flux in these things as pretty amusing, as the younger generation discards and then rediscovers the hard lessons their elders leaned.

The bottom line is: writing good software is HARD. A good developer has a wide array of tools for dealing with the problem, including a diversity of coding styles from OO to functional to procedural and a deep knowledge of multiple lanaguages from APL to zed (neither of which I am a big fan of). "Developers" who are in fact one-language script kiddies are good for fast turn-over low-value applications on the Web, I guess, but at some point the Web environment is going to stablize and professionals will move in to write code that will last decades. This is what happened in the '80s with desktop programming, when a lot of idiots said it was OK to do the job badly because it would be obsolete in the next release. Having worked with code like that which is now nearly old enough to drink in most states, I can say that the judgement of the people who wrote it was bad in all respects.

This will perhaps get replies that say, "But it's different this time!" Sure it is. Now you're writing unmaintainable garbage in JS and PHP rather than FORTRAN, Pascal and C. Professional developers will make a lot of money in a few years cleaning up the mess you're making. In the meantime, we write embedded code that will be running solidly long after you amateurs are gone.

Re:Letting it all out (1)

Pieroxy (222434) | more than 3 years ago | (#35643410)

While I agree in general with your post, I disagree on TDD. Sure, they're no magic silver bullet, but they admitedly add robustness to your code so that when you do some refactoring later on you will be notified if/when you break something obvious. Of course, tricky bugs are tricky bugs and they won't disapear overnight.

However, they do take some time to write and maintain.

That said, rereading the end of your post, I'm kind of implementing my unit tests as if they were interface level tests. Testing String.replace() doesn't make sense to me.

Re:Letting it all out (1)

fish waffle (179067) | more than 3 years ago | (#35643868)

That said, rereading the end of your post, I'm kind of implementing my unit tests as if they were interface level tests. Testing String.replace() doesn't make sense to me.

TDD has some of the same weaknesses as commenting. Adding comments like "// begin for loop" and "// end for loop" make some people feel like they're commenting their code, without actually doing so to any useful effect. Developing trivial tests which verify nothing useful is an easy way to let you pretend you're doing TDD without actually spending enough effort to be effective.

Re:Letting it all out (1)

Pieroxy (222434) | more than 3 years ago | (#35650962)

TDD has some of the same weaknesses as commenting. Adding comments like "// begin for loop" and "// end for loop" make some people feel like they're commenting their code, without actually doing so to any useful effect. Developing trivial tests which verify nothing useful is an easy way to let you pretend you're doing TDD without actually spending enough effort to be effective.

True, but TDD has a big strength over comments: When outdated they fail and so you can update them / clean them up. Of course, testing complex stuff is needed, trivial crap (usually) is useless.

Re:Letting it all out (0)

Anonymous Coward | more than 3 years ago | (#35643554)

I’d also like to note, that I dislike TDD in general (yeah, I know, another flame war)! In my experience, most bugs I find are from running through some kind of manual procedure and noticing something ”odd” that an automated system wouldn’t have picked up. I imagine in web design, where the end result is mainly visual, this would be even more common. Sure, the table has the right values but they are all cut off and too tiny to read.

You make plenty of good observations, but its worth pointing out that there is more to web development than UI and layout design -- form validation, database I/O, etc.

Re:Letting it all out (1)

mclearn (86140) | more than 3 years ago | (#35643568)

"...most bugs I find are from running through some kind of manual procedure and noticing something "odd" that an automated system wouldn't have picked up."

This is a valid point and underlines that automated testing can only be as good as the test designers. If the test designers fail to take into account proper bounds-handling, error conditions, interactions, etc. between modules, then you can -- at best -- protect yourself from regression issues.

I think of testing as an evolutionary process: keep with the tried and true (automation), but throw in some mutations (manual testing) to ensure you are capturing the full spectrum.

Re:Letting it all out (1)

Vornzog (409419) | more than 3 years ago | (#35643786)

From here [idyll.org] :

I don't do test-driven development; I do stupidity-driven testing. When I do something stupid, I write a test to make sure I don't do it again.

If you are the hardcore TDD type, that probably sounds like blasphemy. However, if you don't want to do full on TDD, at least consider SDT. Write tests for stuff you already screwed up - that way you never make the same mistake twice. SDT makes testing another tool for a solid coder (who may make mistakes, because of being human).

Unfortunately, the acronym SDT gives so many more opportunities for embarrassing typos...

Re:Letting it all out (1)

ChunderDownunder (709234) | more than 3 years ago | (#35644950)

It's a great technique when dealing with existing codebases. Take a bug report, write a test. Test fails unexpectedly? Congrats, you just found another defect lurking unseen.
But the assumption that system testers will catch your mistakes is dangerous. Customers only have limited patience.

Re:Letting it all out (1)

Javaman59 (524434) | more than 3 years ago | (#35645854)

Then I believe in SDT++. Write one test that "Concat str1 str2" does the thing it's obviously intended to do. Include that test in the build. After that, add special cases when fault is found.

Re:Letting it all out (2)

syousef (465911) | more than 3 years ago | (#35645042)

I’d also like to note, that I dislike TDD in general (yeah, I know, another flame war)! In my experience, most bugs I find are from running through some kind of manual procedure and noticing something ”odd” that an automated system wouldn’t have picked up.

TDD is a cult/religion, just like most methodologies. I'm sorry but I just won't get religious. I find TDD sounds good and gets people caught up in it, but it fails in 2 very specific ways:

1) It assumes that your design can be so good up front and in advance that the tests can be written first. In practice the specs are always changing and the designs respond by changing both in technical and business contexts. Worse, the frameworks are moving targets and often are so rigid that you must do things their way or end up in a mess. So developers don't have the experience to design with the framework up front without having to tweak for their misconceptions about how their particular frameworks in their current incarnation work. The result is a lot of rework both in the system and in the unit tests.Without a LOT of discipline (unncessary because it provides no tangible benefit) the tests end up being written afterwards anyway. So all you get out of TDD is a mountain of rework of the unit tests - several iterations for each iteration of code instead of just one if you write the test after making the change. This very much makes TDD a case of putting the cart before the hourse.

2) People do become way too reliant on the unit tests giving 100% coverage. In practice this can't be achieved in a timely manner so your coverage even for basic cases (let alone corner cases and complex combinations) tends to be poor. The automated tests lead people to be overconfident and do less manual testings and so quality goes down not up.

Unit tests are better than not having unit tests, so you should be wanting to do that at least. Becoming overly reliant on them however is a silly trap that too many experienced intelligent devs fall into.

It's not you (1)

gillbates (106458) | more than 3 years ago | (#35648894)

Perhaps you just expect to get things done.

TDD's primary goal is to write tests, not to make software better.

Think about that for a moment. You start by writing a test case for a non-existent class or interface. Of course it fails. Then you implement the class. Now the test passes.

Exactly what have you proven? That you can catch an error the compiler or linker would have caught anyway? That you spent a good half hour of your employer's time writing tests for mistakes that neither you nor anyone else are likely to make?

Getting software good and fast is still an art form. Unit testing is good, but it still doesn't address the underlying problem that unless your architecture is specifically designed for change, and unless you develop reusable code, TDD is just another thing which breaks when the requirements inevitably change. With the waterfall method, you had to maintain the code. Now, you've got to maintain the code *and* the tests.

Having run the gamut of development methodologies from as far back as structured coding, I've become convinced that there really isn't a silver bullet; it seems each successive wave of development methodologies only adds more work, more opportunities for error.

Re:Letting it all out (1)

gl4ss (559668) | more than 3 years ago | (#35650046)

tdd is great if you're doing a clone copy of something, 1:1.

if you're doing fresh r&d(what's labeled as such anyways) then.. well, what exactly are you writing the tests for? before you know what to test, before you know which approaches are feasible? well, you don't. with javascript it's even more so.

it's a thing that get's latched on as a company policy and then leads to unit tests being done on weekends for no good reason to justify bonuses counted by test metrics(ridiculous). how the F can you write unit tests if the ui design is still alive? you can, but it's just tests for some intermediate state of the code, actually the only thing unit tests usually test is has the code changed. if it's a proof test for an algorithm, well, then it's not an unit test as such anymore but rather something that coders(and engineers working with tangible objects) have always used.

it's a pretty easy way to write a book or do your thesis, pick a language and then add "test-driven" to the title and then do some silly test harness code around it and voila, you got a book describing something obvious. because doing a test environment is easier than doing anything worth testing.

and actually, js unit tests are only used for testing different js-vm's. and that's a bitch.

Re:Letting it all out (1)

Kintalis (592836) | more than 3 years ago | (#35662926)

Good post. I'm with you on the "I'll take my programming with strong typing and lots of built in idiot-proofing." Personally, I view writing unit tests as an extension of that mentality. I think of it as writing the code twice: write the code (the actual system), and write what the code is supposed to do (the tests). If they don't match, I've done something bone-headed. As long as the tests are part of your build, it's exactly like augmenting the compiler checking. I can't tell you how many times writing tests have caught my own bone-headed mistakes, even in "too simple to be wrong" cases. I'm no TDD fanboy, but in my experience writing tests usually pays for itself pretty quickly timewise.

You mentioned a situation where a refactoring would have been great, except it would break 50 other tests. When I read that, I thought your tests probably did you a favor: that seemingly trivial change would have actually caused a lot of other failures that you didn't expect. Unless the unit tests were badly written. I've seen that before, and yeah... badly written unit tests are as much of a nightmare to maintain as any other badly written code, but without the benefit of providing any customer value! If someone's only experience with unit tests is a poorly written test suite, I can totally understand how that'd sour them on the TDD concept.

Nice. Bought it. (1)

monk (1958) | more than 3 years ago | (#35642852)

I was just looking for something like this.

Ohhh nice! (1)

PmanAce (1679902) | more than 3 years ago | (#35642906)

I had just learnt about and started unit testing with javascript not long ago, it had never occured to me to do some beloved TDD with javascript. I am so buying this, thanks!

Sample the Book from Safari First (4, Informative)

eldavojohn (898314) | more than 3 years ago | (#35643056)

For whatever reason, they left out a few links I put at the end of my submission:

To sample some of the book, check out the Safari Books [safaribooksonline.com] page. Test-Driven Javascript Development is available in many open formats with watermarks [informit.com] or from Amazon.com [amazon.com] .

That Safari link is especially useful if you're on the fence about getting this title, you can view some of the book there. Also, I'm not seeing my score (9/10), publisher information, number of pages (475) or ISBN or any of that.

Developing To Satisfy A Test Is Great, But... (1)

ATestR (1060586) | more than 3 years ago | (#35643436)

My work involves a lot of testing of applications. The big problem seen from this side of the fence is that the tests don't always describe the requirements... as often as not because the requirements change, or they were not clearly stated in the first place. If either of these two things happen, then you can develop to tests all day, but your code won't be any better than if you develop on the fly. If you have solid requirement, it works better either way.

Re:Developing To Satisfy A Test Is Great, But... (2)

slim (1652) | more than 3 years ago | (#35643824)

I think you need to read a good TDD book. Kent Beck's is the standard.

One of the key points is that you don't write *anything* unless it causes a test that was failing, to pass. If all your tests pass, but you know you've got more functionality to add, then you write a new, failing, test. It's a very tight loop of:
- write test
- code until test compiles
- run test -- it fails
- code until all tests pass
- refactor to remove duplicate code (this is where the real wins happen)
- GOTO 10

So, if you're a good enough developer to provide all the functionality that's needed -- then you're a good enough developer to write tests for all that functionality too, because you create a unit test as a side effect of coding each new piece of functionality.

Re:Developing To Satisfy A Test Is Great, But... (0)

Anonymous Coward | more than 3 years ago | (#35644058)

I'd rather have verification built into my production code, otherwise you have two sets of code, the production code and the tests that use bits of the production code in a different environment. Doesn't ADA95 have something like that so you can "verify" your code?

Bit like having a watch you know what time it is.
Two watches, you are not quite sure which is the right time.

I've been involved with projects with 100% code coverage, unit tests etc. Great, but the tests are fragile, change the code and they break, not because the code is wrong but the assumptions/test data is wrong/out of date. The tests tell you what it thinks is going on, not why or how.

So I see developers usually "fixing" the test code instead which makes me worry.

Spec/design doc, bah don't be silly we are doing Agile! ;)

Fast/Cheap/Good. - It is more of a quantum entangled state!

Re:Developing To Satisfy A Test Is Great, But... (1)

slim (1652) | more than 3 years ago | (#35644258)

I'd rather have verification built into my production code, otherwise you have two sets of code, the production code and the tests that use bits of the production code in a different environment.

In a TDD project, you'd treat test code as an equal priority. Sure, the tests aren't included in your compiled deliverable, but you don't distribute the application code without the test code, or vice versa.

You need to design for testability (which just happens automatically, since you're writing the tests first!), such that tests don't rely on external test data. Yes, this means you're testing against mocks and stubs, which might make you worry about what happens if the mock doesn't imitate the real dependency accurately enough. That's fine though -- unit tests don't mean you can avoid end-to-end tests. They just provide a means to develop more quickly and with more confidence.

replace requirements by bugreports? (1)

Anonymous Coward | more than 3 years ago | (#35643610)

been there, done that, and honestly I'm all for it,
provided i get my tester salary + that of the business analyst

jQuery (1)

nate nice (672391) | more than 3 years ago | (#35643822)

"More specifically, I would identify the audience being the poor developers that have slaved over JavaScript for endless hours only to find out that there are 'discrepancies' in how their JavaScript functions in one browser versus another (or even across versions of the same browser"

This is why jQuery exists. Honestly I can't imagine using TDD for any kind of Web project. It costs money to use it in the form of time and the margins just aren't there. The problem with a lot of software development methods is that that kind of process costs money and in the low risk fast changing Web world, those dollars are better spent on another developer, or more expensive developers, that can build shit right and get it through a QA session pretty quickly.

The truth is mainly non-Academic methods of build Webware (I made that up, no you can't use it) just aren't viable. Not because they aren't good ideas or work...but because they cost money up-front and so often there isn't another dev cycle on a project that isn't trivial or requires that great planning was made. Especially on the front end.

Patterns are more important than practices.

Re:jQuery (1)

slim (1652) | more than 3 years ago | (#35643988)

Studies show that TDD saves you time.

[citation needed], I know. But, you know how it is.

My perception is that TDD is not an academic ivory tower thing. It's something pragmatists have settled on as a way to write high quality code quickly and cheaply.

Boring (1)

bmuon (1814306) | more than 3 years ago | (#35646502)

JavaScript is fun. Embrace it! Get a book like Secret of the JavaScript Ninja instead.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?