Try Tuts+ Premium, Get Cash Back!
Meet Crockford’s JSDev
videos

Meet Crockford’s JSDev

Tutorial Details
  • Topic: JavaScript
  • Difficulty: Intermediate
  • Estimated Completion Time: 20 minutes

Recently, Douglas Crockford released a neat tool that makes the process of developing and testing your JavaScript a bit easier. Interested in learning more? Watch today’s quick tip to find out!


Watch the Screencast


Show Link


Will you use JSDev?

I’m curious; is this something that you’ll use in your daily coding? I’m still not sure, myself. Let us hear your thoughts in the comments!

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • w1sh

    Lost me around 5 min in.

    I like your spacey computer theme stuff (“mothership”)

  • Caio Bianchi

    It’s always nice to have some kind of test unit. But he just made the process of building the test too long, and also added a level of complexity that was totally unnecessary.

    PS.: How would you have regular comments with that?

    • http://mastomillers.com Jed

      I know what you mean Caio, but what’s different and great about this is the testing of private variables. Jasmine and others are excellent for testing public and protected, and provide plenty of other tools that JSDev doesn’t, but for inline and private testing this is a great tool! Once you’re in the hang of it, the build process is really very quick. Just takes some getting used to, as with all testing frameworks. Note that other comments without the keywords you supply to JSDev are untouched.

      • xenith

        Could someone explain what “protected” means in the context of JavaScript? Thanks!

      • Gushiken

        @xenith

        If you are a bit into Javascript Prototypes, Closures and the Variable Scope, you can declare variables in a way, they BEHAVE like they are “protected”.

        Just like you don’t really have “private” or “public” functions. But you can put the function into a specific scope, so that it BEHAVES like a private or public function.

  • Wayne

    Posted this on the video, but might be heard here instead…

    How did you get Git branch info in terminal? Wanna share those customizations?

    thanks :)

    • http://nvartolomei.com/ Nicolae Vartolomei

      @Wayne, look at my setup for PS1, from .bash_profile, https://gist.github.com/871284e41058014863e0, actually there are 2 functions returning branch info.

      • Wayne

        Thanks Nicolae, that does help a lot :)

      • http://mastomillers.com Jed

        If you don’t mind the added dependency there’s also vcprompt: https://github.com/djl/vcprompt

        Also, Nicolae, I’m not seeing the code for your arrow prompt in that gist. Where does that come from?

    • Oliver

      I’m guessing that the customisation is from a theme for ohmyzsh:

      https://github.com/robbyrussell/oh-my-zsh/wiki/Themes

      You can tell that it’s zsh not bash by looking at the top of the terminal window.

      If you don’t want to switch to zsh you can check out

      https://github.com/revans/bash-it

      instead.

    • http://www.jeffrey-way.com Jeffrey Way

      Hey Wayne – that question comes up a lot, so I’ll ask Andrew to write an article on his settings.

  • http://nvartolomei.com/ Nicolae Vartolomei

    my setup for PS1, from .bash_profile, https://gist.github.com/871284e41058014863e0, actually there are 2 functions returning branch info.

  • http://ignaciochavez.com Ignacio

    This is cool, but not sure if I’d use it over pure console.log’s , maybe it’s intended for larger scale apps?

    • http://mastomillers.com Jed

      Definitely. It’s nice not to have to toggle console.log on and off, and nice not to have testing code mixed in with the runtime code. There used to be lots of times when I would use console.log to debug a particular function, fix it, remove the console.log (or comment it out), move on, do something else that breaks the function I debugged earlier, add console.log back in, etc. Nice just to write your testing code once and leave it there forevermore.

  • http://github.com/dworthen Derek

    I think JSDev has great potential for users whom are new to test driven development. Otherwise I do not think JSDev is worth it. Sure it looks pretty sweet as test framework but I believe that as a script gets larger and may even span multiple files I will want to pull my tests and test fixtures out of the comments section and use an actual test library, just another level of separation. I would state that this looks good for maybe smaller scripts but even then I have an issue, how does JSDev work with other comment based “tools?” like JSDoc.

    It would be nice to see in the future JSDev work well with tools such as JSDoc, in that case I would probably use JSDev. Maybe JSDev could create two files when executed, the file with all of the extra test code and another file which is similar to the original one just without all of the comments related to JSDev specified by those passed in keywords. That way the file with the remaining comments can be used with JSDocs or the likes of it. Now JSDev would not have to create both files with one command but it could create various files based on flags passed to the bash command, now that would be ideal.

  • http://andrewburgess.ca Andrew Burgess
    Author

    Hey guys,

    Thanks for your comments! I agree that it’s hard to see how JSDev will integrate with the other testing tools we’re used to, but I think I’m going to give it some time and see what my workflow turns out like. You shouldn’t have to worry about JSDev messing with “normal” comments, because it will only modify multi-line comments with the prefixes that you specify when calling it. Just thinking out loud here, but it wouldn’t be to difficult to create a little “wrapper” script / shell function that creates a JSDev version and a minified version of the script, all at once.

    And for everyone asking about my terminal: I did write a tutorial on customizing your shell a while ago (http://net.tutsplus.com/tutorials/other/how-to-customize-the-command-prompt/), but that was more basic. So, stay tuned for an article (or maybe video) on how I’ve customized my terminal. :)

  • checkov

    Hi
    Thanks for the screencast. As far as I understand… The make_counter function uses the revealing module pattern, which uses nested functions to make variables private, and the point of JSDev is to overcome the fact that this nesting makes unit testing difficult.

    Apologies for the possibly silly question but, would it not be better to put an underscore in front of the variables you wish to make private (so as to communicate to colleagues “please don’t touch this”) and avoid the nesting -and hence JSDev -entirely? (I’m learning Python too, that seems to be the mindset there)

    I suppose what I’m after is a reminder of why truely private variables are a good thing! I just read http://net.tutsplus.com/tutorials/javascript-ajax/stop-nesting-functions-but-not-all-of-them which says: “what about privacy? Well that’s simple: don’t do it.” (I assume Crockford would disagree)

    Thanks for any thoughts

    • http://andrewburgess.ca Andrew Burgess
      Author

      You could begin private variables with an underscore, but then you just have to *hope* that no one will mess things up. I prefer to use closure when I want to keep a variable private, because that guarantees that only I have access to it. I’m not familiar with Python, so I can’t speak to that part of it.

  • http://www.7ooof.net/ 7OOOF.net

    COOL thanks!

  • http://www.simonsimcity.net Simon Schick

    Very nice tool if you want to write server-side code. It does not seem to make that much benefit if you’re modifying the DOM :) and seems therefore useless for me ….

  • Americo Savinon

    Pretty Cool Video.

    I don’t think I will use JSDev though. Having testing code inside my source code seems a little bit unnatural for me. I like much more Jasmine’s approach for testing.

    We will see how it progress, but I’m not convinced on using it.

  • http://blog.gotofritz.net fritz

    I kind of see the appeal, but having tests mixed with the code in the same file doesn’t appeal. Also, I didn’t see an “include” paramater, so it doesn’t look like I can easily share tests across files, meaning I would have to redefine areEqual etc every time.

    The only thing that looks interesting is the code parameter, normally I’d pass a ‘debug’ var to my functions (or have a global) and have debug methods enabled when that is set to true. I only use those for debugging rather than testing, but JSDev could be an interesting alternative.

  • http://www.joezimjs.com/?utm_source=net.tutsplus.com&utm_medium=referral&utm_campaign=comment Joe Zim

    I can see this as being useful in some rare cases, or if you’re one of those people who test every tidbit of code. Other than that normal testing like Unit tests should work just fine in most cases. I’ll still have to mention this on my blog, though: Joe Zim’s JavaScript Blog

  • dch

    For people saying “I don’t want to mix tests in with my code”, that’s not the point of JSDev imo. That’s a bad idea to begin with. This is a good way of getting access to variables or functions that are “private” via closure which you would otherwise have no access to. You provide access to those internal structures for your test suite, but they remain hidden and unavailable in your production code as you *probably* intended.

  • just_a_dude

    great video thanks
    compiling JSDev right now to start using it … having used Jasmine and QUnit I think this is a time saver

  • https://github.com/kirbysayshi Andrew Petersen

    Thanks for the great video. The README is a bit difficult to really tell what’s part of JSDev and what is defined, and your video helped clarify that.

    I also made some more examples of using JSDev in this gist: https://gist.github.com/1712319

  • http://www.viniciusweb.com.br/ Desenvolvedor Web

    I will test this development tool for js and verify that contributes!!!

  • monica darky

    For people saying “I don’t want to mix tests in with my code”, that’s not the point of JSDev imo. That’s a bad idea to begin with. This is a good way of getting access to variables or functions that are “private” via closure which you would otherwise have no access to. You provide access to those internal structures for your test suite, but they remain hidden and unavailable in your production code as you *probably* intended.
    لپ تاپ