What are you working on? April 2012

David_Gerard

This is the bimonthly 'What are you working On?' thread. Previous threads are here. So here's the question:

What are you working on?

Here are some guidelines:

Focus on projects that you have recently made progress on, not projects that you're thinking about doing but haven't started.
Why this project and not others? Mention reasons why you're doing the project and/or why others should contribute to your project (if applicable).
Talk about your goals for the project.
Any kind of project is fair game: personal improvement, research project, art project, whatever.
Link to your work if it's linkable.

This is the bimonthly 'What are you working On?' thread. Previous threads are here. So here's the question:

What are you working on?

Here are some guidelines:

Focus on projects that you have recently made progress on, not projects that you're thinking about doing but haven't started.
Why this project and not others? Mention reasons why you're doing the project and/or why others should contribute to your project (if applicable).
Talk about your goals for the project.
Any kind of project is fair game: personal improvement, research project, art project, whatever.
Link to your work if it's linkable.

learn how to test specific modules

Could you tell me more about this -- what is the best method and tool for unit testing in JavaScript? In Java I use JUnit for the non-GUI parts, and the GUI parts I simply don't test... perhaps I should test them too, but in my programs most of complexity is in the non-GUI parts, so if I test them, most of the work is covered.

JavaScript feels more integrated with the GUI (the browser). In theory, it is an independent language, which can be embedded in browser or in anything else, and all the browser stuff is just like an additional library. When I will write more complex JavaScript programs, I want to write them in the way that separates the program logic from the browser API. And I would want to unit-test the logic. Shortly: I would like to unit-test JavaScript code in a JUnit style, not in a "browser emulation" style. What would be the best approach to do that? Also with regards to browser emulation or integration, which are the best tools? I have tried some (Canoo WebTest, Selenium), and they seem rather inelegant when compared with JUnit testing. Although Selenium also has a programming mode that seems more friendly; I haven't tried it yet. I would appreciate some help here, so I don't have to study and experiment with dozen tools.

especially for javascript, I cannot stress enough the value of having even a basic reversion control system of "copying the folder and renaming it after each major stable milestone".

Yep, this is my blind spot. I know I should do it, I don't do it, and I often run into problems that this would prevent. I'll try to remember to install Subversion at home. Thanks for reminding me about this!

Regarding unit testing JavaScript, I recently asked this question myself at Stack Overflow (and if you're not familiar with Stack Overflow and the Stack Exchange Network, I recommend you should; it is a great place to get answers for technical problems), and ended up using Jasmine. I'm skeptical of the “BDD” thing, but it seems a perfectly fine tool for unit testing. I'm using it (example) to test logic inside the browser — that is, I load a web page which runs the tests and becomes the report of results — but I understand it can also be used from a “headl... (read more)

4kpreid14y

Subversion was good for its time, but a new generation of version control systems has sprung up — DVCSes (“distributed” version control). The new model is superior even for individual developers; some examples: * To get started all you have to do is enter a command to “turn this directory into a repository (a versioned directory)”, rather than having to choose/set up a server, access control, layout, naming schemes, etc as the “centralized” model (CVS, SVN, etc.) requires. * In a typical centralized VCS, when you commit changes, they are permanently in the repository as a new version; if it turns out you made a mistake, not in your code, but in how you added it to the repository (e.g. forgot to include a file), you have to make a new revision. With DVCSes, you can prepare your changes as a series of individual commits/revisions and polish and revise them before making them part of the permanent/public record. The major benefit of this for development is that it means you can commit often — every time you have made an improvement, commit it, thus preventing yourself from accidentally overwriting it without record during further development. If you make a mistake, or if the changes you made turn out to be a bad idea, you can always revert to last commit without losing anything else; and the diffs between revisions become single-topic, so more straightforward to understand. I personally favor Git as being quick to use and flexible, but Git is generally considered obtuse in its command syntax so I wouldn't specifically recommend it to someone new to version control. There are also Mercurial (hg), Bazaar (bzr) and Darcs (that last being a bit of an oddity in itself). I recommend against using Subversion for new work.

0The Dao of Bayes14y

Unfortunately, I do Javascript using notepad, so I can't really help you on tools. I'd usually just write a "UnitTest" function and put my code there. From the browser, you can directly invoke a function, so you'd just do "UnitTest();" or "UnitTest_Module8();" and have them display results in the form of alerts or such. Another useful technique is to add a label or textbox to the HTML, and then keep running debug information there, for tracking variable that you suspect might be getting set wrong. I'd also often scatter alerts through my code, just so I could tell "Okay, it has reached this point in the code" or "Okay, at this point, x=5" IMO, the major power of javascript is the ability to run commands "on the fly" from the browser itself, and the ability to very quickly modify the source code and re-run the program.