5 ms·
The problem with that is that unit tests are so useful during refactoring. If you have enough unit tests, you can pretty much refactor at will without worrying
by tsally 17y ago
The problem with that is that unit tests are so useful during refactoring. If you have enough unit tests, you can pretty much refactor at will without worrying about your program silently breaking.
- gaius 17y agoIf you are using a language that is amenable to it, you can refactor at will and the IDE will verify its correctness. Many people use unit tests as a crutch for a lack of strong typing.
- tsally 17y agoThis isn't always (or even usually) true. Sure, the IDE will verify the compile time correctness of the code, but unit tests check for run time correctness. So if you refactor a method to add an additional parameter, unit tests will catch the null that Eclipse inserted into all method calls to make the code compile.
- gaius 17y agoBut that is not refactoring, that's adding a new feature!
- tsally 17y agoIf you are changing the signature of a method that is part of the implementation in order to improve readability, clean up design, or remove dead code, it is refactoring. Refactoring isn't just as simple as renaming classes and methods; it often requires more significant changes than that. Example: /* old */ LoadWeapon(WeaponTypeEnum type); UnloadWeapon(WeaponTypeEnum type) LaunchWeapon(WeaponTypeEnum type); /* new */ WeaponCommand(WeaponTypeEnum type, WeaponCommandEnum command); Note... assume that the interface is a GUI, so changing these methods doesn't change any external interface.
- wlievens 17y agoNot really. Reordering declarations, for instance, is a "safe" refactoring, though not when you're using reflection at some point.
- eru 17y agoThe nulls point to a lacking type system.
- eru 17y agoYou'd need a halting problem solving IDE for this to work in general.