Thursday January 26, 2006
If you start working on an existing project (like I did recently) it is always a problem to find out, who is responsible for which parts of the code base. For this scenario a research team at UCI has developed an eclipse plugin, which analyzes Java code in a CVS repository and spits out a dependency graph - both for code and developers.
If you mix this kind of software with the principles of social software one can stipulate software re-use in large-scale, distributed systems and teams (think of SOAs). Great stuff IMO!
Posted on Jan 26, 2006 at 20:37 (MET) |
Permalink |
Thursday January 26, 2006
Martin Fowler has posted a plug for Gerard Meszaros’ book about patterns for automatic testing with the various XUnit frameworks (the author is probably a thoughtworks fellow). However Gerald has categorized objects used for testing:
- Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
- Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryDatabase is a good example).
- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
- Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting.
Posted on Jan 26, 2006 at 20:19 (MET) |
Permalink |