Sure I'll try to take a look
4,546 karma · joined October 27, 2009
That's really useful for some tasks, like regurgitating code to perform a specific function, but it's basically useless for jobs like estimating schedules.
"-> AI" is just the next step along that journey. Maybe it will end at "-> AGI" and then humans will engage in programming mostly for the craft and the pleasure of it, like other crafts that were automated away over the ages.
His thesis seems broadly to be that by accepting gifts whenever they're offered, he is making the world a better place - opening himself up to kindness somehow encourages kindness in others. This is nonsense and totally backwards. What he's doing is just soaking up a whole world of goodwill and generosity, and giving basically nothing in return. "Paying it forward" is a chain - people do nice things for each other in the hope that the recipients of that goodwill will provide similar generosity to others in the future and together we make the world better for all of us. It's socialised good will - creating a rising tide that lifts all of our boats. The author of this piece has instead acted as a kind of capitalist, moving into a space with abundant resources (i.e. the generosity of others), and harvesting as much as he can, wondering at how much resource there is available for him to take, marvelling that others leave it there for him when he would likely not do the same, and patting himself on the back for taking it so that more can flow into the space.
It's somewhat akin to high frequency traders claiming that they benefit markets by providing liquidity.
Maybe we should all just follow his example, and then none of us would have anything left to give each other. Narcissistic nonsense.
...or, you tested each thing individually, so only related tests break and you can quickly zero in on the problem. Isn't that easier?
This is what I mean about a well-factored code base; separate things are separate, and can be tested independently.
> Unit tests have proven more harmful than helpful
Why? I find them very useful. If I change a method and inadvertently break it somehow, I have a battery of tests testing that method, and some of them fail. Nothing else fails because I didn't change anything else, so I don't need to dive into working out why those other tests are failing. It's separation of concerns.
If your unit is thousands of functions wide then you have a monolith, and there are widely discussed reasons why we try to avoid those.
Not to labour the point here, but no, the primary reason you isolate variables in a scientific experiment is that you want to ensure you're only testing the thing you intend to test. A medical study is a good example - you want to be sure that the effect you observed was due to the drug you're testing, and not some unrelated lifestyle factor.
Thanks for sharing your views on the rest; there was just one thing I wanted to expand on:
> Now let’s say you mock something in your function. Let’s say you make a change to that but the input and output are the exact same. Now you have to update your test.
I think the scenario you're describing here is: a function's dependencies have changed, but the inputs and outputs of that function have not; therefore even though the behaviour is the same, the tests still need to be updated. Is that right? In which case I would say: of course you need to update the tests - the dependencies have changed and therefore the behaviour of the function depends on different things and you need to model the behaviour of those new things in order to properly test the original function. To me this objection only holds if you are mainly focussed on code coverage; however, to me, good testing exercises the same code paths in multiple different ways to stress the code and ensure that the results are correct given all possible inputs. The dependencies of a function are also inputs of a kind.
You seem to say it's not worth writing a lot of tests, but then you talk about tests breaking due to bad changes - if you don't write those tests in the first place, then how do you get into that situation?
I didn't word my earlier comment very well - I don't mean to advocate for 100% coverage, which I personally think is a waste of time at best, and a false comfort at worst. Is this what you're talking about? What I wanted to say is that unit tests should be written for every part of the code that you're testing, i.e. break it into bits rather than test the whole thing in one lump, or better, do both - unit tests and integration tests.
Unless that whole paragraph was a figure of speech, in which case what I said doesn't apply, and we can both go about our days.
OK; it's your choice to do what you think is right.
> and comparing it to scientific experiments doesn’t really apply.
Why not? I think it's a fairly apt comparison; you have a theory ("this piece of code does the following things"), and write tests to prove it.
> You can do all that without mocks as well.
OK, but mocks make it easier and cleaner - so why wouldn't I do that?
> Making the tests run faster at the expense of better tests seems counterproductive.
Smaller, more focused, cleaner tests are better in my opinion; speed is a beneficial side effect.
> Now you should think of reasons why you should not isolate.
Why? That's your argument - it's not on me to prove it for you. If you can give me some good reason why mocking out the interfaces you are not testing is a bad idea, and some better alternative, then we can have a discussion about it.
Hopefully one day you'll back at that, and realise what an immature attitude that was.
To easily simulate failure cases, a range of possible inputs, bad data etc.
To make the testing process faster when you have hundreds or thousands of tests, running on multiple builds simultaneously across an organisation.
Off the top of my head :-)
What you're describing is a very limited subset of testing, which presumably is fine for the projects you work on, but that experience does not generalise well.
Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously.
Apart from that, databases and file access may be fast but they still take resources and time to spin up; beyond a certain project and team size, it's far cheaper to mock those things. With a mock you can also easily simulate failure cases, bad data, etc. - how do you test for file access issues, or the database server being offline?
Using mocks properly is a sign of a well-factored codebase.