tag:blogger.com,1999:blog-1973750947775262558.post1483601613554898658..comments2008-07-03T11:40:34.864-04:00bill sheltonhttp://www.blogger.com/profile/06624894387927690246noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-1973750947775262558.post-16987001266238360802008-07-03T11:40:00.000-04:002008-07-03T11:40:00.000-04:00big time. the notion of groups of tests is very cool. and i know you shouldn't care about test order, but i can see how this would be useful.<BR/><BR/>i really like the whole "method interceptor" approach, too. TestNG got their shit togetherMarc Esherhttp://www.blogger.com/profile/05942611191966201181noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-87065113815479156732008-07-03T11:14:00.000-04:002008-07-03T11:14:00.000-04:00@mike - super-cool use of sql-05!<BR/><BR/>@all - One of of the numerous things about the TestNG approach that struck me was the ability to control the execution threads of tests: "You can also define new groups ..., such as whether to run the tests in parallel, how many threads to use, whether you are running JUnit tests, etc... "; e.g., <BR/>@Test(threadPoolSize = 3, invocationCount = 10, timeOut = 10000)billhttp://www.blogger.com/profile/06624894387927690246noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-75373573929410272312008-07-03T10:03:00.000-04:002008-07-03T10:03:00.000-04:00yer right, mike, the plugin does work that way in that it runs each test function as a separate webservice request. technically, only one object is created, and it's put in an object cache, and then subsequent calls to each test just pull that object from the cache. but the difference is that there's no request scope to speak of, and each function gets run in a single "operation" inside CF so to speak.<BR/><BR/>i'm really curious though why you're having the problem when you run it in the html test runner. i wish i was sitting beside you now to watch it because this sounds like a fun problem to solve.<BR/><BR/>also, we're heading out for stogies today during lunch. too bad you're down in the hood and not up here in sunny owings mills!Marc Esherhttp://www.blogger.com/profile/05942611191966201181noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-29595331516773894362008-07-03T09:56:00.001-04:002008-07-03T09:56:00.001-04:00If you're using mssql 2005, you absolutely want to take a look at the new snapshots feature. I'm able to do a complete back and restore around each one of my database method tests. It's pretty amazing how fast it is; maybe a second or two to do the backup and about the same for the restore.<BR/><BR/>This goes hand in hand with the "develop locally" approach. You definitely don't want to use this approach with a database that isn't just yours. <BR/><BR/>One caveat that I have, though is that some of my db test fail if I run them with anything other than the test runner embedded in the eclipse plugin. It's very strange. It's almost like the plugin runs tests serially and the html test runner runs them in parallel. Trying to run tests in parallel while doing backups and restores in between probably ain't gonna work.<BR/><BR/>When it does work, though, it's pretty freaking amazing.Mikehttp://www.blogger.com/profile/02592223337712827862noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-86672390224673312822008-07-03T09:56:00.000-04:002008-07-03T09:56:00.000-04:00@marc - funny you should mention that! I had similar thoughts this morning with respect to creating and loading tables with data. This also speaks to the some of the TestNG/annotation stuff we've been discussing and some of Mike Rankin's thoughts. You could have a @BeforeSuite annotation that creates tables and data needed for the fixture, and then once all tests are run, you could call @AfterSuite to drop the tables ...<BR/><BR/>billbillhttp://www.blogger.com/profile/06624894387927690246noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-15303564577996249272008-07-03T09:10:00.000-04:002008-07-03T09:10:00.000-04:00just thinking out loud: it'd be cool if you kept the DML scripts (create procedure, etc) in source control. then your test could fetch the script, strip off the "create..." junk and just run the guts of it. this way, you wouldn't duplicate your "real" db code and you'd always be testing the most recent. it'd help keep the tests from going stale, too.<BR/><BR/>just a thought....Marc Esherhttp://www.blogger.com/profile/05942611191966201181noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-83670776205063171762008-07-02T09:36:00.000-04:002008-07-02T09:36:00.000-04:00@aaron: yeah, it seems like there's a pretty big need, or at least a desire, to have some ways to test databases. I was only able to touch on that briefly at the testing talk at CFUnited, but several folks mentioned afterwards that they really wanted some more info on the subject. Stay tuned ...<BR/><BR/>thanks,<BR/>-billbillhttp://www.blogger.com/profile/06624894387927690246noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-42882980822253604672008-07-02T09:24:00.000-04:002008-07-02T09:24:00.000-04:00thanks! I'm excited to hear more on this, and appreciate you taking the time to explain your take on how to unit test databases and queries via MXUnit.Aaron Longnionhttp://www.blogger.com/profile/03864976259628767766noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-27718222208290578962008-07-01T14:07:00.000-04:002008-07-01T14:07:00.000-04:00got it. thanks!billhttp://www.blogger.com/profile/06624894387927690246noreply@blogger.comtag:blogger.com,1999:blog-1973750947775262558.post-85556125522279751142008-07-01T13:52:00.000-04:002008-07-01T13:52:00.000-04:00nice!<BR/><BR/>one thing: in that test, if your assertion fails, the debug() won't fire.Marc Esherhttp://www.blogger.com/profile/05942611191966201181noreply@blogger.com