Now there are frameworks for DOM manipulation (jQuery, dojo, YUI), for common tasks (Underscore, YUI, Closure), and there are architectural frameworks (Knockout, Backbone) as well. As you can see, they are fractured and you must use different frameworks for different tasks. You should choose well because it’s very very hard to change frameworks, and you have to watch out for compatibility. Framework version changes represent huge risk in the lifetime of a project. Even a minor version change can render your web application totally useless. So test heavily.
No we have two ways. Full manual testing with a lot of humans. Or follow the ‘new’ trend and use some kind of automated test frameworks (Selenium, Watir). If they work the way you think. If it’s not more time to maintain your tests than execute them manually.
The same applies to unit tests. There are various frameworks in different flavors (xUnit, BDD, etc.) with different capabilities and APIs. Some live long, some live short. Choose well. Update regularly. Follow the news, trends.
Well, I chose a unit testing framework. Now I should test my code. How? It produces HTML into the DOM and calculates things according to different business rules – in the same function. Well, good luck. Try separating your business logic from visual stuff. Rings the bell? MVC? MVVM? Well, I’d say Knockout and Backbone. I’d say use (revealing) module pattern for your view model and your rendering as well. Separate them. Use a framework, e.g. Require.js. If you do it good, you can even get rid of the inheritance and other OO problems. Now you can test your business logic separated from the UI.