4 ms·
More importantly, why Apple doesn't run test suites, basic checks? Test driven development must be everywhere
by homakov 13y ago
More importantly, why Apple doesn't run test suites, basic checks? Test driven development must be everywhere
- raverbashing 13y agoBecause TDD in low level languages is a pain in the behind. And sometimes impossible In Python/Ruby sure, it's easy. In Java, or even C++, it's doable, but not great, and it requires some heavy tricks. But they surely need tests, but not necessarily TDD.
- nailer 13y agoAck re: TDD, but integration tests with a bad certificate would have picked this up.
- homakov 13y agoNot testing everywhere, but "smoking test" that your SSL implementation protects from MITM, at all, and none of your programmers screwed it (with gotofail or anything else). This is what I expect from an OS developers
- raverbashing 13y agoYes, something that would test all the steps of the SSL authentication and possible failures Maybe the people from OpenSSL have some test like that already
- stcredzero 13y agoAnd sometimes impossible I've been in that position. Sometimes with embedded, you can't have software fixtures, only hardware ones. (Bit banging)
- raverbashing 13y agoTell me about it And you think you know what the device answers and understands, but there's usually some gotchas.
- danpalmer 13y agoTest driven development is actually quite uncommon in many parts of the industry. Sure the startup culture and new breed (new bubble?) tech companies mostly emphasise it, but among older companies it's much less common for a few reasons: 1. It just wasn't considered normal practice until fairly recently. 2. They often use 'lower level' languages, and as @raverbashing mentions, they're more difficult to test. 3. The companies are much slower moving, so arguably have less of a risk with not having automated testing. Automated testing has more benefits in agile than it does in the waterfall methodology.
- laureny 13y agoTDD might be useful for unit tests (even that I'm not convinced of) but not for integration tests. The bug happens very deep inside the handshake protocol and it's extremely hard to test it automatically.
- stcredzero 13y agoHow about verifying a bad cert?
- landypro 13y agoThat's hardly an excuse given the significance of this code.
- dllthomas 13y agoRight, this is a much stronger case for static analysis and warning-free builds. This change caused dead code. If that code was supposed to be dead, comment it out.
- ryandrake 13y agoIf the code is supposed to be dead, DELETE it. Do not comment it out. If the code doesn't belong there, get rid of it. If, for whatever reason, you want to show the reader that code used to be there, delete it and leave an explanatory comment. If you're commenting it out because you're not confident in taking it out or you plan to re-enable it in the future, well, that's what you have source control for.
- dllthomas 13y agoI don't agree. Or I do to a point, but it's a relatively weak point. I agree code should be yanked if there's no reason to be keeping it around. I don't think there's never reason to be keeping it around. Sending people to figure out which version of the repository had the relevant piece of code (which is now correspondingly less likely to have been updated at all when surrounding code changed) doesn't make sense if you genuinely expect it will be relevant again soon.