nrinaudo

Any dynamic language - by definition, they check types at runtime.

Or, unfortunately, a lot of static languages. Any static language that allows type casting, for instance - that's the only way they can check whether a cast from a type to one of its descendants is valid (eg, in Java, casting an Object to a, say, URL).

You say that like it's a bad thing, but that's what a static language is - types are checked at compile time and, hopefully, forgotten about at runtime.

But java.util.Date is mutable where a long isn't, and that's a problem. People can mutate a Date from under your feet if they manage to get a reference to it. This has a lot of far reaching implications, but essentially, unless you protectively copy all values of type Date you get or give, you can't trust your own internal state. You can't write a legal equals or hashCode implementation that uses a date field. The list goes on.

Don't do java.util.Date.

I hate to be that guy, but in the fourth paragraph, the author mentions the variance issue as old news.

And else is used more than if...

But still, you end up with tests for what the author feels his code should handle, not necessarily what the real world is actually like.

Don't get me wrong, that's still valuable - if only for the non-regression aspect - but I feel property-based testing is a superior approach.

Write your code ("this is a function that sorts lists of ints"), write a property ("when given a list of ints, after sorting it, elements should be sorted and the list should have the same size"), let the framework generate test cases for you. Whenever something breaks ("lists of one element come back empty"), extract the test case and put it in a unit test to make sure the same issue doesn't crop up again in the future.

What do you mean, you should not be testing internal implementations anyway? Does that also mean you don't do unit test, only integration or end-to-end ones, because unit tests are tests of the internal implementation of your software?

Or, you know, write property-based tests instead, so you only need to worry about the logic and not the test values.

I've always found that if you let the author of a piece of code decide on what value that code should be tested with, he'll test for the edge cases that he's thought of (and dealt with), not the ones that actually crash production.

I thought the concept entertaining, up until I read the bit about "rape causing little to no long lasting harm to the victim". Shame, this could have been a fun, if weird and selfish, thing.

I agree with part of your sentence only. Managers, especially professional ones (as opposed to ones that were promoted from the kind of position they end up managing) do tend to push for client-facing features with little thought to the accumulating technical debt.

It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.

There might not be such a distinction in France. It was a summer job with some level of mentoring, which we just call "internship". It's entirely possible that this is what Americans would call an apprenticeship, my vocabulary is not wide enough to know for sure.