If Ide Vendors Concentrated On Test Rigs Instead Of Debuggers

I may have said this before. Just to be sure, I'll say it now. The issue of the debugger is language specific. For example, in modern SmallTalks the debugger is integrated with the Unit TestingFramework, and is really useful to better pinpoint the location and cause of bugs. It is also possible to edit the code from the debugger and continue running it from the point of interruption, with no need for recompilation. -- Victor (from the XpMailingList)

If IntegratedDevelopmentEnvironment makers focused on tests...

• wizards would create both code and the TestFirst rig the wizard author used to generate that code

• the source browser would distinguish between ProductionCode & TestCode?, and would flip automatically from a TestCase to its target code

• the Go button would not ask any stupid questions, such as "you want to save files?" or "you want to compile?"

• Undo would have the ability to roll back to any previous GreenBar

• there'd be an Integrate button - NOT a bunch of goofy checkmarks on each file stating if it's "checked out".

• integrating would run the tests, and would back the integration out if the tests failed.

• ExtractMethod would be on the toolbar

• at assertion failure time, the IDE would know both the call stack of the production code and the fixture of the assertive code

• the Workspace panel on the left would default to a fourth tab, containing the test suites and cases

• one could run any subset of tests, or any superset of folders with tests, from the IDE

• Imagine all the effort the past 2 decades spent on debuggers, spent instead on test rigs.

-- Phlip (on the XpMailingList, and ignorant of both Smalltalk IDEs and Eclipse)

---

Drool... Many commercial IDE's (MSVS, CodeWarrior) have plugin interfaces for doing these kind of enhancements. Anyone want to take a whack at it? (and make a ton of money?)

---

EclipseIde already does a lot of these things. You can edit code in the debugger and continue from the last frame on the call stack (unless the edit changes methods in previous frames). The JUnit plug-in will create test cases and test suites for you. [JunitWithEclipse] The source browser doesn't distinguish between production code and test code per se, but I'm not sure what the advantage of that would be. Compilation happens on every save, and saves can be automatic when you run or debug. ExtractMethod is just one of many refactorings on the menu bar. The call stack of the production code and fixture is the same (they run in the same VirtualMachine and share at least one thread), so I don't understand how the IDE couldn't know both of them. The panel on the left has a tab for unit test suites and cases. One can run any set of tests or suites from the IDE. And it's free. -- EricHodges

---

DrScheme plus SchemeUnit is a start in this direction -- at least you can start a GUI test runner from a button on the toolbar.

---

Extract Method would be on the toolbar.

How is this related to test rigs or debuggers?

Pull out a chuck from a large method so it is callable in a unit test

I interpreted this the other way around: having written my TestFirst, I want to ExtractMethod the part that should be used in production.

---

CategoryIde