Let's Code: Test-Driven Javascript | Hacker News Reader

Let's Code: Test-Driven Javascript

kickstarter.com

56 pointsjdlshore23 comments

I think this is a reasonable product, but don't understand why it's a Kickstarter project. If the author has been developing a similar series for Java over the last year and a half, why does he need funds to do it for JavaScript?

I think the Kickstarter concept is fantastic for things that need to be fabricated, where building in bulk is a significant cost difference. But it seems like there's a trend where people sell products that don't actually need start-up capital through Kickstarter just to get an advance. This project may be worth the money, but I find the trend worrisome.

I imagine Jim needs funds because after doing the Java course he now fully understands how expensive in time and money producing a long series of tutorial videos can be :-)

Because doing it again in JavaScript, editing, producing, and hosting the videos takes a time and money. Using Kickstarter acts as a handy piece of customer discovery and lets him know that there is a market that is willing to part with actual money.

Hey, it's Jim! I've been to one of his classes - it's provocative stuff, really changed the way I think about development -- although most of my takeaways were about project management rather than about testing style.

There's a whole little community of really bright thinkers about Agile process in the Pacific Northwest - Jim Shore, Arlo Belshee, Ward Cunningham, Diana Larsen - who, mostly, seem to mostly talk face-to-face rather than posting things online, so the HN crowd may not be getting the benefits of what they come up with. I'd love to see that change.

(Here's a beer, Jim.)

Thanks. Cheers!

Nice. Backed. My JavaScript TDD saw is verging on blunt - so I hope it makes the target :-)

Out of curiosity - which testing framework (if any) are you using for the JS testing? I've played with some of the ones on http://openjsan.org/ but haven't found anything that really hit the spot for me.

Also - I just love the idea of using KickStarter like this. I'm very tempted to steal the idea for some "UX for Developers" sessions I'm building.

Thanks! I'm using Nodeunit on the server and JsTestDriver on the client, for now. I prefer TDD-style tests to the BDD-style tests of something like Mocha.

On the client, I'm using JsTestDriver because of its excellent cross-browser/cross-platform testing support. In the past, I've used it to run tests against IE 7, IE 8, IE 9, Safari, Chrome, Firefox, and iPad Safari simultaneously, with one command (and a bunch of VMs / slave browsers).

That said, the Javascript world is changing extremely rapidly these days, so I'll re-evaluate these choices after the project is funded.

I highly recommend you consider using mocha with the TDD interface rather then nodeunit.

[I recently evaluated different node testing libraries](https://gist.github.com/b0382064a4ddac608b8c), which may help with your own evaluation.

Thanks, I'll take a second look. Nothing's set in stone.

Ohhh,... Mocha outputs TAP. Didn't notice that before. That's going to make my life easier :-)

As an alternative, see: Test-Driven JavaScript Development (the book) http://tddjs.com/

This is great! I came across your Let's Play TDD series couple days ago, from another HN post. I'm not a JavaScript beginner, but needless to say, I love your approach of teaching and this is the first project I've ever supported on Kickstarter. I hope to learn a thing or two. Good job.

Hmm, I think these were the videos I was watching a while back. I didn't end up finishing watching them because they were Java based... A JavaScript version should help expand that audience quite a bit.

You're probably thinking of my Let's Play TDD [1] series. You're right--it's been enough of a success that I wanted to bring it to a more relevant platform. Also, I see a lot of people who don't do rigorous Javascript testing, even if they use TDD elsewhere. It seemed like there was an opportunity to help improve the state of the practice.

[1] http://jamesshore.com/Blog/Lets-Play/

Is anyone using QuickCheck as the testing part of a TDD process? Does it work?

There are quickcheck-derived libraries for Javascript, one of them by Douglas Crockford.

Thanks for making this as accessible as you are! I would love to see more practical pieces on TDD, especially for the web.

How will you be sharing the source code? I would love to see TDD happen with a test committed followed by a commit to pass the test, etc. to get a sense of the full process or write my own passing code for each test and compare against another implementation.

You're welcome! I haven't decided how I'm going to share source code. For my current series, I'm committing after every episode and posting on GitHub [1], so I'll do at least that much. Your idea of committing after every step of the TDD cycle is a really interesting one, but I'm not sure if could do that without it detracting from the videos. I've added it to my list of neat ideas.

[1] https://github.com/jamesshore/lets_play_tdd/commits/master

Hmm... thinking about this further, it shouldn't be too hard to have a wrapper for my build script that stores the most recent pass/fail state, then automatically commits when that state changes. The trick would be not polluting the continuous integration or end-of-episode branches. I'm sure it can be done, but my git-fu is weak and it would take some research. Might be a good stretch goal reward if funding goes well...

Thanks for the reply! Good luck with reaching the funding goal - interested to hear how things go and if you do work out a way to get the build script working as well.

Okay, I did it. :-) I'm not sure how useful/readable the result is, but check it out and let me know what you think.

https://github.com/jamesshore/Autocommit

Awesome! Thanks for making this happen. Have downloaded the git repository and will take a look soon.

Maybe this: in "draft mode", you automatically commit on all changes in pass/fail state. Then, at some point, you "publish", at which point you squash all the commits from commit X to HEAD whose message matches "[ON RED]".

I imagine git rebase -i X | sed -i "magic happens here" would do the job.

I have started doing this for my training courses. When I demonstrate live, I commit to git. I use some variation of "FAILING" in the commit messages to call attention to "red" commits, in "violation" of the usual rule that tests pass 100% in all commits.

azundo, I know my examples aren't web apps, but do you have time/energy to explore any of the branches in this code base[1], read the commits, and give me feedback on how easily you follow it?

[1] https://github.com/jbrains/WorldsBestIntroToTdd-Tallinn-Janu...

Will also take a look and let you know! I'm not a serious java dev but can usually parse a bit of code here and there so will try and get you some useful feedback.

Reply on news.ycombinator.com