5 ms·
The unit tests worry me: assert len(WORDS) == 32192 assert sum(WORDS.values()) == 1115504 assert WORDS.most_common(10) == [ ('the', 79808),
by falsedan 9y ago
The unit tests worry me:
assert len(WORDS) == 32192
assert sum(WORDS.values()) == 1115504
assert WORDS.most_common(10) == [
('the', 79808),
('of', 40024),
('and', 38311),
('to', 28765),
('in', 22020),
('a', 21124),
('that', 12512),
('he', 12401),
('was', 11410),
('it', 10681)]
assert WORDS['the'] == 79808
Those aren't testing the file open, or Counter, or read, but instead are tightly-coupling the tests to the exact corpus. The code really should have not hard-coded the corpus, and the tests should have supplied a smaller corpus of known length where each word's frequency+probability was obvious from inspection.
There's another overfitted test just before this:
assert Counter(words('This is a test. 123; A TEST this is.')) == (
Counter({'123': 1, 'a': 2, 'is': 2, 'test': 2, 'this': 2}))
What is this verifying? We know how a Counter works, we don't need to test it; and the previous test already established the correctness of words().
I see a lot of junior engineers following this style of tightly-coupled, overfitted tests, and seen how a few years of growth can lead to tens of thousands of tests whose primary value is to provide Amazon with a predictable stream of AWS revenue (as we run all th tests) & make the engineer feel better for writing tests.
- cdancette 9y agoThis code is not written for production, it's just written to make you understand how the basic of this technology works. So I would say the unit tests have the exact same purpose: make the reader understand what the functions are doing (and not a real unit testing). Since you speak of value, the value Peter Norvig is trying to provide is making readers understand the principles, he's not trying to provide some monetary value. So I don't think your criticisms apply here, those tests fit the purpose very well.
- dmurray 9y agoThe value he is trying to provide is also showing people by example how to write readable, idiomatic, functional Python code. From that perspective, I agree the tightly coupled unit tests are a bit grating. Though they would not look out of place as doctests.
- falsedan 9y ago> the value Peter Norvig is trying to provide is making readers understand the principles, he's not trying to provide some monetary value I think he's trying to show how to approach solving this kind of problem. Juniors will copy it, and will then write tests in a business-logic environment which have dubious value. The code shows how to solve the problem very well. The tests do not.
- perfmode 9y ago"They" are Peter Norvig. I mention this not to appeal to authority, so much as to remind you that you're not reading the code of a junior engineer.
- caioariede 9y agoThose asserts seem like a pre-Jupyter form of narrative.
- scott_s 9y agoHis tests are appropriate because they are task-oriented. He is not writing a general spellchecker, but a spellchecker designed to work with a specific corpus. His tests ensure that the corpus remains unchanged during development (say, doesn't accidentally remove some words). What's implicit here is that if the corpus changes, he may need to change his approach.
- falsedan 9y ago> What's implicit here is that if the corpus changes, he may need to change his approach. Will that be obvious to a junior engineer? (I think that's the target audience for this article) If I was writing such an article, I would (maybe) call that out as explicit, or (extremely likely) remove those tests so as not to accidentally implicitly recommend overfitted tests as a useful technique.
- partycoder 9y agoSome tests are similar to the "texas sharpshooter fallacy".
- abecedarius 9y agoThis is a fair criticism, I think. Anyone want to write a blog post about the tests they would write for this task? Maybe it'd be especially interesting as going from "here's what you might do for the first version coded on a plane flight, now here's how it might evolve as it's polished for publication". I'm not volunteering as I'm not especially good at writing tests.
- djtriptych 9y ago1. Read blog post. 2. Opine on how blog code is not ready for production. 3. Post to HN. 4. Propser.
- inteleng 8y agoThis is a 1% engineer? The guy who can't spell "prosper"?
- djtriptych 8y agohahaha man. Thank you. I upvoted :)