When you are practicing JustInTimeProgramming, your approach is different. You write tests first and code afterwards. Wouldn't it be nice to have an environment which made that easier? How about a tool in which you write fixtures for test cases? Every method that you use on a class in a test generates a method body in the class under test. If you execute, you are immediately presented with the empty body and you fill it in. Kind of like KentBeck's method defining function in JustInTimeProgramming. As it stands, developers doing UnitTest''''''ing in C++ and Java end up having to do a lot of manual manipulation and jumping around. A tool should be able to infer types of method arguments from the call. If you want to change them to the types of base classes, that is fine too. It just seems that in many cases you shouldn't have to type the same things over and over.

-- MichaelFeathers

EclipseIde has some of these features. ''PleaseComment further.''

-- DavidVydra

I agree with Michael. "I have a dream..." Some IDEs have tight integration with the type system of the language (syntax coloring, auto-completion, symbol lookup, etc.). How about an IDE that has tight integration with the TestingFramework? Envisioned workflow:
* Add a class or method.
** After writing the signature, up pops the skeleton of the tester for this method. Perhaps it is prepopulated with boilerplate tests based on types of the parameters.
** You write tests, and then can conveniently flip back and forth between the tester and the method body. Perhaps these are two panes that are always visible for a method.
** New tests are automatically linked into the testing framework. If you can compile it, it will be tested.
* Modify a method.
** Up pops the unit test, with warnings of which tests may now be obsolete based on changes in the method signature.
** Even cooler: prepopulated with boilerplate tests based on an analysis of the control structures in the method and the unit tests in the called methods. (I'm envisioning programmatically generated tests from BrianMarick's test catalogs in TheCraftOfSoftwareTesting.)
*** Or vice versa: asking to edit a method would always take you to the method tester first.
* Any automated refactoring will automagically update the appropriate unit test.
* Automatic generation of MockObject''''''s for every non-leaf object?
* Some means to quickly open and edit the test framework setup/teardown methods for object/method testing.
* Compile
** Running the unit tests would be an integral step in the compilation process. Dependencies between tests and methods would be automatically generated.
** Any test failures would naturally take you to the offending method and test.
** For some languages (Smalltalk), this could even be done at the method level for very fast GreenBarCycle''''''s.

Rationalle: if StaticTyping is tightly integrated into languages and IDEs to save time by validating changes at compile time (or even edit time), why not extend this to the more general validators of UnitTest''''''s.

Admittedly, a lot of this would have to be language specific. Smalltalk would probably be the easiest to implement, integrating into the RefactoringBrowser, but I would sure like to have something like this for C, C++ or Java.

-- IanOsgood

---- 
TestDrivenDevelopment