If you subscribe to this blog, you may have noticed that I’ve been writing about test automation methods a lot lately. You could even think of it as a series covering different technical approaches: * Hosting your app in a real web server and testing it through a real web browser using WatiN (plus, in this case, SpecFlow for Cucumber-style specifications)
* Hosting your app in a real web server and testing it with client-side automation using Microsoft’s Lightweight Test Automation Framework
* Hosting your app directly in the test suite process and bypassing both the web server and the browser entirely using my MvcIntegrationTestFramework experiment
* Unit testing code in isolation – best and worst practices, and why I think unit testing isn’t applicable to all types of code
* Injecting code across process boundaries to assist integration testing approaches that host your app in a real web server, using Deleporter The reason I keep writing about this is that I still think it’s very much an unsolved problem. We all want to deliver more reliable software, we want better ways to design functionality and verify implementation… but we don’t want to get so caught up in the beaurocracy of test suite maintenance that it consumes all our time and obliterates productivity. Yet another approachRails developers (and to a lesser extent Java web developers) commonly use yet another test automation technique: hosting the app in a real web server, and accessing it through a fast, invisible, simulated web browser rather than a real browser. This is known as headless browser automation. Read more: Steve Sanderson’s blog
* Hosting your app in a real web server and testing it with client-side automation using Microsoft’s Lightweight Test Automation Framework
* Hosting your app directly in the test suite process and bypassing both the web server and the browser entirely using my MvcIntegrationTestFramework experiment
* Unit testing code in isolation – best and worst practices, and why I think unit testing isn’t applicable to all types of code
* Injecting code across process boundaries to assist integration testing approaches that host your app in a real web server, using Deleporter The reason I keep writing about this is that I still think it’s very much an unsolved problem. We all want to deliver more reliable software, we want better ways to design functionality and verify implementation… but we don’t want to get so caught up in the beaurocracy of test suite maintenance that it consumes all our time and obliterates productivity. Yet another approachRails developers (and to a lesser extent Java web developers) commonly use yet another test automation technique: hosting the app in a real web server, and accessing it through a fast, invisible, simulated web browser rather than a real browser. This is known as headless browser automation. Read more: Steve Sanderson’s blog
Posts
0 comments:
Post a Comment