Gotcha. I run VirtualBox with an IE8 and IE9 VM for JsTestDriver, BusterJS, or the like. For Selenium though, I use SauceLabs to run it on all sorts of browsers and they actually provide you with a video of the test too. It's not free, but it's definitely worth the money.
"It's mainly to ensure that while I'm changing something in one place I don't inadvertently screw up a page someplace else that I may forget to check."
It all comes back to design by testing. Personally, my apps use a lot of layouts, views, and helpers so an automated way to check that a change in one place doesn't affect my UI somewhere else is paramount.
The key here is that it's automated. I use continuous integration, and introducing even one human element breaks the flow of quick pushes and updates.
As for sketching out page design, "form follows function." I'm not thinking about the look of the app at all. I'm not a designer, but once my HTML is written I can show a talented designer exactly what they have to work with to create the best UI/U possible. Basically, I'm not a fan of design-driven development.
I wish I could attach an image so you could see where I am with my current project. It's a logo at the top, followed by a list of links, a dropdown, another list of links, some content, etc. One on top of the other, no design at all. Black text, white screen. It is very clear though what the page is suposed to accomplish. Let the designer do their job, and I'll TDD my CSS when I turn their vision into code.
My reason for TDD HTML: I'm a firm believer in "form follows function". I'm trying to employ test-driven principles to design by forcing us to think about the function of the UI by writing tests first. Once the features are well defined by tests, we start writing our CSS and Javascript.
I'm not a Ruby guy so I've never used Watir. You pass the HTML string into Watir and it parses it in a headless web browser. Then you use Selenium WebDriver for generating screenshots to manually review? Makes sense.
My only concern is that it's not test-driven. My next post will be on browser testing as verification, but the reason I like TDD so much is because it forces me to think through the problem before writing code.
"It's mainly to ensure that while I'm changing something in one place I don't inadvertently screw up a page someplace else that I may forget to check."
It all comes back to design by testing. Personally, my apps use a lot of layouts, views, and helpers so an automated way to check that a change in one place doesn't affect my UI somewhere else is paramount.
The key here is that it's automated. I use continuous integration, and introducing even one human element breaks the flow of quick pushes and updates.
As for sketching out page design, "form follows function." I'm not thinking about the look of the app at all. I'm not a designer, but once my HTML is written I can show a talented designer exactly what they have to work with to create the best UI/U possible. Basically, I'm not a fan of design-driven development.
I wish I could attach an image so you could see where I am with my current project. It's a logo at the top, followed by a list of links, a dropdown, another list of links, some content, etc. One on top of the other, no design at all. Black text, white screen. It is very clear though what the page is suposed to accomplish. Let the designer do their job, and I'll TDD my CSS when I turn their vision into code.