Hello all,
For some time, I have been running new tests programmatically vs. using the SUnitBrowser. New tests are likely to fail, so a Do-it is much quicker than hunting for a specific test method in the browser, hitting the run selected button, and then hitting a couple of things to enter the debugger. None of this takes away from the browser; it's great when tests should pass or to find the ones that fail. Now for the correction. I have used SomeTestCase new testSomething which bypasses #setUp and #tearDown. Using SomeTestCase run:#testSomething seems to do the job correctly. If there are any problems with that, please let me know. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
> Now for the correction. I have used
> > SomeTestCase new testSomething > > which bypasses #setUp and #tearDown. Using > > SomeTestCase run:#testSomething > > seems to do the job correctly. If there are any problems with that, > please let me know. Still not right =:0 This seems to work: ( SomeTestCase selector:#testSomething ) runCase. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill:
I also think that using the test GUI is kinda painful, especially if you want to test a single class, and then test a whole bunch of classes. I normally test the heck out of the class I'm changing, and then when it's finished, I test ALL other tests that could possibly be broken by my changes. It really seems painful when you've done what I've done, which is load a bunch of goodies, that included lots of tests, ESPECIALLY some tests that are designed to fail. This means that if you press RUN ALL, you end up ALWAYS getting the red screen,and have to browse the reported errors. And if you don't press RUN ALL, you have to scroll around, finding and clicking on every particular test you want to run. What I ended up doing was adding an "appOrCategory" variable to the test cases, and altering the GUI to show this field. That way, all of the tests that belong to a selected "appOrCategory" could be run as a single bunch. This way, if my application is, say a time keeping app, all of the tests with "Time Keeping" in the appOrCategory variable can be tested with a single click, and I don't have to worry about running tests for objects that I haven't messed with. Of course, before I'm completely done, I run EVERY test for EVERY thing, since I do manage to screw up things across application boundaries quite a bit ;) Brody |
Brody,
> I also think that using the test GUI is kinda painful, especially if > you want to test a single class, and then test a whole bunch of > classes. I normally test the heck out of the class I'm changing, and > then when it's finished, I test ALL other tests that could possibly be > broken by my changes. Just to clarify, I think the SUnit Browser GUI is great, but I find it painful to use when I "know" I just broke something - that's when I want to be able to just get on with the debugging, and do-its are the way to go. > What I ended up doing was adding an "appOrCategory" variable to the > test cases, and altering the GUI to show this field. > > That way, all of the tests that belong to a selected "appOrCategory" > could be run as a single bunch. Nice! Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
> Just to clarify, I think the SUnit Browser GUI is great
I couldn't agree more. The entire framework is just too cool. But for the scenario you described, your idea makes a lot of sense, and I'm starting to use your method when I'm actively changing a class, and know that I'm breaking stuff. |
Hello all,
>>Just to clarify, I think the SUnit Browser GUI is great > > I couldn't agree more. The entire framework is just too cool. > > But for the scenario you described, your idea makes a lot of sense, and > I'm starting to use your method when I'm actively changing a class, > and know that I'm breaking stuff. Given that my goal is to get walkbacks if there is a problem, and to evaluate silently if all is well, I have finally added a method to (hopefully<g>) achieve that behavior. As it was, I was getting confused between #run and #runCase, and had to keep testing to see which is the preferred selector :( If you try this and find that it deviates from the plan, please let me know. Sorry for the confusion. Have a good one, Bill !TestCase class methodsFor! prod:aSymbol "Run the test; do nothing if ok or go to a walkback." #wksSafe. ( self selector:aSymbol ) runCase. ! ! !TestCase class categoriesFor: #prod:!public! ! -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |