Christian Johansen

author
+ Follow
since Oct 03, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Johansen

Congratulations guys! Hope you'll enjoy the book. Thanks everyone for having me, it's been fun
That's the easy way to do it If you use a library, like Sinon.JS, you can do



The upshot of using a library is

1) You get a richer interface for behavior verification (i.e. was it called? how many times? what arguments did it receive? and so on)
2) Sinon sandboxes the test and reverts the original method after the test has run

Beware that IE not always allow you to override host methods like this. I don't remember if it screams when overriding alert, but you'll notice soon enough
The best way to do redirects is on the server. You should make sure to send a 301 Moved Permanently, so spiders also get updated. With Apache you can do this like so:



You _really_ should do this on the server. To answer your original question, this is one way to do it, but I don't recommend it:

No. jQuery can help you solve/smooth over cross browser issues, unit tests can help you verify that your code works across browsers. Also, unit tests can help you verify that your logic is correct and that the code behaves as expected. Simply using jQuery cannot guarantee that you won't run into cross-browser issues or that your code does what it should. They are completely different. Also, TDD is a matter of helping you design and implement code.
Hi Mark,

Sure, you can start testing even if you already have existing code without automated tests. As you improve your test coverage, you will experience a rise in productivity as the need for manual testing is reduced.

The book doesn't use any existing libraries for examples mainly because I didn't want to tie it to a specific library. However, through the book's second part (which teaches advanced JavaScript topics using unit tests to illustrate behavior) I build a small library which is used for the real world sample projects in part 3. So, yes, I show TDD-ing when using _a_ library, but really your choice of library doesn't really matter much. They're just APIs
JsTestDriver does not have any mocking/stubbing capabilities. I use Sinon.JS (disclaimer: I wrote it), which works great with JsTestDriver.
Test stubs are much like mocks in that they are fake, but unlike mocks, stubs aren't preprogrammed with expectations. So you use state verification as usual in tests that use stubs (either on the stubs or other objects). Martin Fowler has a great writeup on the difference: http://martinfowler.com/articles/mocksArentStubs.html
Yes, most of the examples are written using JsTestDriver, which makes testing across browsers really easy.
Filipi, I don't really have a lot of experience with rendering tests like these. As you say, it could be very helpful, but at the same time very difficult to implement properly, because what is decent rendering in a given browser is really a human decision. For example, on the project I'm currently working on, we strive for as a good an implementation of the design as possible, but glitches in e.g. IE6 are always weighed against the assumed time to fix them. In other words, we accept "worse" rendering in some browsers than some others, and we rarely expect pixel-perfectness.

With that said I did come across this a little while ago: http://mogotest.com/blog/2010/08/18/automated-cross-browser-render-issue-detection Haven't tested it, but it looks interesting.
IE8 (and 9) have pretty good debug tools. There is also Firebug Lite, which is embeddable: http://getfirebug.com/firebuglite

If you ask me, the best way to debug your application is to write unit tests for it ;)
Hi Jeff,

No, there are no direct tests for using alert and other browser popups. The alert function could possibly be stubbed/mocked in order to verify that it's being called, but as a host function, that might prove difficult in some browsers. Alternatively, you can define your own function, e.g. mylib.dialog("Hello") which by default uses alert, and then test that this function is used as expected.
Hi Andrew,

That's a good question! Unfortunately the DOM is made up of what is called "host objects", which are barely specified in the Ecma Script specification. As a result, behavior between browsers vary, sometimes a lot. So the DOM is usually used as is when testing rendering logic (i.e. code that builds/manipulate DOM elements), and the unit tests can help you uncover browser inconsistencies. With that said, with a little planning, you're free to stub and mock in what way you want for most of the code/tests.

There are several ways to remove direct DOM dependency from your code. One way is to separate the logic that updates the view to separate object(s)/function(s). These can be substituted with mocks in the test so you can test that it gets the right method calls at the right times. Thus you are free to keep testing "core functions" without worrying about the DOM. As it turns out, this is good practice anyway, because it separates your app logic from the rendering part, resulting in easier to share components.

Another way of avoiding the DOM when testing methods that do simple manipulation of elements is to simply pass an object that defines the method/properties needed by the function you are testing, e.g.:



Both of these approaches are explored in the book in more detail than what I've written here.
The book has instructions for setting it up, but I don't spend a lot of time on the Eclipse plugin. The book is primarily focused on the concepts of testing, not the tools themselves.

Personally, I prefer the command-line, and use my own autotesting tool for jstestdriver: http://cjohansen.no/en/javascript/jstdutil_a_ruby_wrapper_over_jstestdriver
Hi Helana,

A unit test is a small piece of code (function/method) that exercises some other code and verifies its expectations of its results. Unit tests typically test single behaviors of a system in isolation, and is aimed at catching method-level errors and providing a safety-net in which regressions can be caught. In TDD unit tests are also used to drive development and to guide the design of the code.

Unit testing is a developer activity, which sets it apart from how some large organizations do acceptance testing, as an example (i.e. organizations that have their own QA department/people).
Hi Kurt,

Actually testing helps with dealing with multiple browsers and inconsistencies between them. By running a suite of tests across browsers you have a much easier time figuring out which browsers fail which parts of your implementation. As bugs are uncovered by the tests, they can be coded around and solved in the implementation (possibly by extracting certain browser abstractions as separate functions/objects) you will be able to finally pass all tests in all browsers. Now you know that a solution works, and any regressions at a later point is easily caught by the same (and new) tests.

Of course some browser differences are so unexpected that unit testing will allow you to simply stumbling over them all, but once you identify strange behavior in a browser you can write a test which forces the situation to occur and make sure your code copes.

You don't need to emulate all this crazy behavior, because the tests actually run in the browser. Thus, when the tests pass (assuming they have reasonable coverage), your implementation should be cross-browser reliant.