>in my opinion, because users don't care about "custom widgets," "queues," or "databases."
Users care quite a lot when these things break.
>They care about business functionality, which is quite easily expressible in model form.
They care about reliable applications that do the task they want. Users don't have a concept of "business functionality". If a widget they wanted to use is broken, they'll be pissed - they won't tell you that it's ok because the concept of the application was still good.
From your link:
>The main thing that I want to highlight here is how simple the model is. This is pure domain logic, and is probably as close to the essential complexity of the application that we can get
This is exactly the issue.
If I go down my recent list of bugs and categorize them, ~8 out of 10 of them are in areas which the author would have *abstracted away*. The other two probably could have been avoided by having a team member write one test to cover that functionality instead of zero.
What does it mean when you abstract something away from a test? Well, it means the test won't catch a bug in that thing.
If I went down my recent list of bugs and been able to see that 9 out of 10 of them would have been caught via adding property testing/model testing on top of regular testing/typing, etc. I'd have absolutely no second thoughts about implementing it but that simply isn't the case.
I have worked on problems in (not usual) environments where it is the case, and in those rare cases I have advocated for and used property testing but I have more often seen it advocated and used by people who see every bug as a nail and property testing as some kind of super advanced hammer.
Users care when their expected behavior breaks. They certainly do not care why it broke, or _where_ it broke. Most users don't know what a database is.
> If I go down my recent list of bugs and categorize them, ~8 out of 10 of them are in areas which the author would have abstracted away.
Even though the model is abstract, all of the behavior of the implementation is covered in a model-based test. For example, let's say a SQL query is what's broken for some use case. This query would be exercised in the test, and it wouldn't pass until the query is fixed. That's the main reason I prefer model-based integration tests - there are no such bugs that escape.
Also, I still write targeted tests. There's nothing that prevents you from doing that, and it absolutely is useful in many cases. I just believe that most tests should be generated, and hand-written tests should be the minority.
Users care quite a lot when these things break.
>They care about business functionality, which is quite easily expressible in model form.
They care about reliable applications that do the task they want. Users don't have a concept of "business functionality". If a widget they wanted to use is broken, they'll be pissed - they won't tell you that it's ok because the concept of the application was still good.
From your link:
>The main thing that I want to highlight here is how simple the model is. This is pure domain logic, and is probably as close to the essential complexity of the application that we can get
This is exactly the issue.
If I go down my recent list of bugs and categorize them, ~8 out of 10 of them are in areas which the author would have *abstracted away*. The other two probably could have been avoided by having a team member write one test to cover that functionality instead of zero.
What does it mean when you abstract something away from a test? Well, it means the test won't catch a bug in that thing.
If I went down my recent list of bugs and been able to see that 9 out of 10 of them would have been caught via adding property testing/model testing on top of regular testing/typing, etc. I'd have absolutely no second thoughts about implementing it but that simply isn't the case.
I have worked on problems in (not usual) environments where it is the case, and in those rare cases I have advocated for and used property testing but I have more often seen it advocated and used by people who see every bug as a nail and property testing as some kind of super advanced hammer.