Why static typed languages are sometimes better.
David Bolen
db3l at fitlinxx.com
Fri Jul 2 03:56:43 EDT 2004
More information about the Python-list mailing list
Fri Jul 2 03:56:43 EDT 2004
- Previous message (by thread): Why static typed languages are sometimes better.
- Next message (by thread): Why static typed languages are sometimes better.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Roy Smith <roy at panix.com> writes: > Amazingly, the test passed (that means I'm done, right?). Well, it took > me a moment to realize that the only thing I ever do with the argument > in the current version is use it as a dictionary key. (...) Note that independent of the static v. dynamic question, to answer your question, no, the test passing doesn't mean you're done - at least not if you're following a TDD approach. In TDD, the first step is to write a _failing_ test. If the test you write doesn't initially fail, that's a red flag that should be examined. Now, it may turn out the test is ok, the code is in fact ok, or even that the new test is superfluous. But it also may mean that the test is incomplete or that it exposes something the code was previously doing that needs adjusting. In this case, if the only code that ever accessed the key to the dictionary was your routine that was passing the new test, you may in fact be done, since just storing the tuple in the dictionary still satisfies your tests. Conversely if the tuple should result in distinct dictionary entries, then presumably that's what your test should be validating, so something may be missing from the test to enforce the desired behavior. In any event, the lack of a failure should immediately make you study the situation, as you obviously did, and figure out just what is going on. -- David
- Previous message (by thread): Why static typed languages are sometimes better.
- Next message (by thread): Why static typed languages are sometimes better.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list