Your testing should be included in your development effort. If there is a client that outright asks you to quote them without unit/integration/acceptance testing, you should refuse them a support contract.
And probably just refuse their business outright.
I suppose you could refuse their business or refuse to support them, but I'm a bit more interested in educating and sharing the value of testing.
It's a concept that doesn't have a lot of direct parallels in other fields. If your plumber suggested installing a test unit in your toilet to make sure they did the job right you'd probably be a little dubious. 😁
Most don't outright ask for a quote without those things, they just don't understand what they are or why they're paying for them.
I'd challenge the idea that other fields don't test. That toilet was meticulously tested in development. The flange the plumber is installing was tested against multiple toilet models. When the plumber finishes their installation, they're going to turn the water back on and flush the toilet a few times.
All different kinds of testing : unit, integration, and acceptance or e2e.
Interestingly, I had this exact same conversation with someone else after this discussion. We came to a similar conclusion.
Unit tests are like machines that test other machines. It's like that Ikea drawer they claim you can open and close over 1 million times. How do they know you can open and close it over 1 million times? They have a machine that opens and closes the drawer a million times.
Correct. Perhaps it's the development community which is behind on the notion of wrapping in testing with their day to day work. Seemingly everyone else does it on the regular.
I agree with you. Whenever someone says let's add a task in the user story for unit testing, I ask not to. It should be part of that other task called development.
This is generally what we do, but it's not uncommon for a potential client to ask why we quote much higher than someone else who just didn't include testing or unit tests in their quote.
Being able to explain the importance and the direct value they get from it is an important part of helping them make an informed decision.
When I hired a contractor to do my front stairs, the contract he provided me with did not specifically include the time he will take to do the necessary measurements. It is always assumed, whenever we are building anything, that we must take the time to measure everything first.
So there is no need to explicitly state in your agreement/contract that you need extra time for writing unit tests (i.e. for measuring before you cut). Anyone who complains about a craftsman spending some time measuring is quite clueless, i.e. as you say, we should refuse to do business with such foolish 'customers'.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your testing should be included in your development effort. If there is a client that outright asks you to quote them without unit/integration/acceptance testing, you should refuse them a support contract.
And probably just refuse their business outright.
I suppose you could refuse their business or refuse to support them, but I'm a bit more interested in educating and sharing the value of testing.
It's a concept that doesn't have a lot of direct parallels in other fields. If your plumber suggested installing a test unit in your toilet to make sure they did the job right you'd probably be a little dubious. 😁
Most don't outright ask for a quote without those things, they just don't understand what they are or why they're paying for them.
I'd challenge the idea that other fields don't test. That toilet was meticulously tested in development. The flange the plumber is installing was tested against multiple toilet models. When the plumber finishes their installation, they're going to turn the water back on and flush the toilet a few times.
All different kinds of testing : unit, integration, and acceptance or e2e.
Interestingly, I had this exact same conversation with someone else after this discussion. We came to a similar conclusion.
Unit tests are like machines that test other machines. It's like that Ikea drawer they claim you can open and close over 1 million times. How do they know you can open and close it over 1 million times? They have a machine that opens and closes the drawer a million times.
Correct. Perhaps it's the development community which is behind on the notion of wrapping in testing with their day to day work. Seemingly everyone else does it on the regular.
I agree with you. Whenever someone says let's add a task in the user story for unit testing, I ask not to. It should be part of that other task called development.
This is generally what we do, but it's not uncommon for a potential client to ask why we quote much higher than someone else who just didn't include testing or unit tests in their quote.
Being able to explain the importance and the direct value they get from it is an important part of helping them make an informed decision.
When I hired a contractor to do my front stairs, the contract he provided me with did not specifically include the time he will take to do the necessary measurements. It is always assumed, whenever we are building anything, that we must take the time to measure everything first.
So there is no need to explicitly state in your agreement/contract that you need extra time for writing unit tests (i.e. for measuring before you cut). Anyone who complains about a craftsman spending some time measuring is quite clueless, i.e. as you say, we should refuse to do business with such foolish 'customers'.