NIce blog post. I agree that MVC can create circular dependencies, because I have been in a project where we had circular dependencies in our MVC.

Mocking may be a solution to inject the view, when it is not possible to create it in a test scenario. If we use a library such as EasyMock, we may not have to create an Interface for the view and a mock implementation.

The view and the controller can also be decoupled using events, where the view registers itself for ModelChangedEvent in the model (by getting the model from the controller).

But nevertheless, I do agree that data binding is a very desired feature, as is reverse data binding.

Thanks to your articles, I have better understanding about testing JavaScript. But I have a question that can “js-test-driver” test browser extension?

I am currently working on a project building extensions for three browsers, Safari, Chrome and Firefox, and am looking for a good test framework that can cover these browsers on Windows 7 and Mac OS X. The extensions will be pure JavaScript, CSS and html only.

I wonder if you have any recommendation that can meet the requirements?

1. API testing. Different browsers provide different extension APIs and we want to cover our extensions’ APIs which built on top of these APIs.
2. JS code coverage.
3. Works on both Mac and Windows.
4. good reporting system.
5. performance data.

Other low priority items:
1. crash dump information, javascript call stack…
2. UI automation-> through UI, since extensions sometimes create buttons and toolbars on the browsers not in the web content.
3. browser rendering time, this is different from the javascript performance data.

I appreciate any your help.

Thanks,
Wei

updated the link with higher resolution video.

Glad to hear that yo are getting some use out of this blog. I don’t think anyone has ported Testability Explorer to other languages, but I don’t follow .Net, so I don’t know of any useful metrics there.

I enjoy reading your articles and perspective on testing. We have legacy code that is not very testable. Two things I have taken on / been tasked with are:
1. having our developers write more unit tests and more testable code;
2. gathering some valuable metrics.

I have read a lot on metrics, and know that they can be absolutely worthless and cumbersome if done incorrectly. The best advice I have seen is that you shouldn’t follow a fixed recipe, but instead, determine what is important to you, and gather metrics around that.

With that, one thing that is very important to us is having more testable code going forward. I’m curious if anyone has taken on porting your Testability Explorer to c# / .Net?

Also, I’m open to any thoughts (or links to articles) you have on this subject.

Thanks!
Damon

I suggest you take a look at “MVVM” Model-View-ViewModel, it is a variation on the MVP & MVC methodologies that leverages data binding for creating a highly testable model representing the view seperate the specific UI controls (hence ViewModel). A lot of what is out there is geared more specifically to WPF and Silverlight, but the concepts and goals are aligned with what you are investigating here.

Just a thought, thanks for the great blog!