4 ms·

Good tests do indeed not test the detailed shape of inputs and outputs, they test the system end to end. And they should be cheap to run, so you run them after

Good tests do indeed not test the detailed shape of inputs and outputs, they test the system end to end. And they should be cheap to run, so you run them after every change. As soon as someone mistypes jobId the test will break and you will know where to look. If that would slip through then your tests simply aren't good enough. And because tests do not test the detailed shape of inputs and output it becomes easier to try out a quick refactor of your code later, without having to change a zillion signatures just to experiment a little. Agility matters.

RUnconcerned 2y ago
I'm very fond of end-to-end system tests, with any external dependencies mocked out using something like Wiremock for HTTP calls, and containers for databases or queues. If it were up to me, I'd only have that kind of test, and some unit tests for pure functions/methods that may have finicky logic. You misunderstood my point about the `job`/`jobId`, though. It would be correctly typed, and wouldn't break anything. But it would not be immediately clear for a developer working on that code in the future if it was an instance of Job or the ID of a job, and there would be no type information that immediately makes that clear. I don't feel like the point you are making with regards to changing the signatures is true, either. If you're changing the shape of some data structure, or adding/removing parameters, then you would also have to make those changes in a dynamically typed language, it's only when you're changing the types of the parameters that you have to make a change, but that's really not that big of a deal, since your development environment should helpfully point out the places you need to update as you change them. I value code that's easy to makes changes in, but I value code that someone else can quickly pick up more.

RUnconcerned 2y ago

I'm very fond of end-to-end system tests, with any external dependencies mocked out using something like Wiremock for HTTP calls, and containers for databases or queues. If it were up to me, I'd only have that kind of test, and some unit tests for pure functions/methods that may have finicky logic. You misunderstood my point about the `job`/`jobId`, though. It would be correctly typed, and wouldn't break anything. But it would not be immediately clear for a developer working on that code in the future if it was an instance of Job or the ID of a job, and there would be no type information that immediately makes that clear. I don't feel like the point you are making with regards to changing the signatures is true, either. If you're changing the shape of some data structure, or adding/removing parameters, then you would also have to make those changes in a dynamically typed language, it's only when you're changing the types of the parameters that you have to make a change, but that's really not that big of a deal, since your development environment should helpfully point out the places you need to update as you change them. I value code that's easy to makes changes in, but I value code that someone else can quickly pick up more.