Excuse me, I’ve worked with various JS-based projects on both front-end and back-end in different teams. We all did TDD and ATDD, and we’ve never written these "type-system-substitute" tests.
Instead, we’ve tested only behavior from the user perspective.
In these codebases, I’m pretty sure, there are few functions here and there, that would behave incorrectly if you were to call them with e.g. a number instead of a string argument. But that is not a problem because nobody does that, because there are higher-level acceptance tests (e2e + integration) that ensure that behavior is consistent.
So the "in theory, but in practice" argument kind of doesn’t stand. At least not in my view of the world and experience.
Have had many hats on in my life: Developer, Team Lead, Scrum Master, Architect and Product Owner. Now back to developer \o/ Interested in product discovery, quality assurance and language design.
I'm sure that tests have little to do with static or dynamic typing, or statically proven languages. Every corner case or circumstance that your function can be called in should be tested. It is true, however, that in dynamic languages there are more circumstances under which you function can be called. I don't find it a significant difference, though.
As of statically proven languages, the only difference is that your tests don't need to run - but they need to exist.
Having said that, after working with C++ for 15+ years, I now value dynamic typing for it will not break your whole build if some detail does not work correctly or is not yet implemented - especially the last part is valuable, IMHO. You can write the code that calls your function before having written it at all, and still execute the rest of your tests. Feels good for gradually turning tests green.
Have had many hats on in my life: Developer, Team Lead, Scrum Master, Architect and Product Owner. Now back to developer \o/ Interested in product discovery, quality assurance and language design.
Every corner case or circumstance that your function can be called in should be tested
I agree with this ONLY if we’re talking about a library that is exposed to any user out there potentially.
If we’re talking about the application code where the team has full ownership of the full stack (as it should be), then there is no need to be testing the function how you do not expect to be called (but it could be potentially).
That’s because you’re not writing a function in isolation, it is part of one or multiple code paths of a bigger size. Potentially several layers of architecture, and if e.g. your business domain code is calling this function only with strings (and it would be absolutely non-reasonable to call it with something else), why should you spend your time and time of everyone else in the future (when running test suite) on testing what will happen if you pass a number (or anything else)?
When you have higher-level tests, that check what happens when multiple components and layers are integrated within various user/business acceptance scenarios, you’re going to confirm that function indeed is called properly at all occasions (implicitly).
Of course, if you don’t trust your team members to do the right thing, then you should work on that trust issue, find its root cause(s) and work through fixing it. Please, don’t fix people problems with technological complexity.
Have had many hats on in my life: Developer, Team Lead, Scrum Master, Architect and Product Owner. Now back to developer \o/ Interested in product discovery, quality assurance and language design.
You're totally right. The statement came out a bit too pedantic, and yes, I was thinking more of code used by a wider audience. Because, from my usage experience of libraries in dynamic languages, I've learned that it is very frustrating when you accidentally passed in the wrong type, just to get seemingly random error messages four calls down the stack. And that partly confirms @combinatorylogic
's statement "most of the tests for the primitive dynamically typed languages are nothing but a poor men substitute for a type system.", although, as I said, I don't think that the tests that do substitute a type system are too much of a burden.
Again, I'm talking about widely used code here, not your team's shared libraries where you can tap the original author on the shoulder to get help with it if it spills out gibberish error messages.
You're doing it the right way then, good! I'd always take integration tests vs. any amount of unit tests. The problem is with all the people who perceive weak typing as an invitation to write tons of pointless unit tests, I'm sure you've seen it happening a lot.
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.
In theory - yes, of course.
In practice - nope, most of the tests for the primitive dynamically typed labguages are nothing but a poor men substitute for a type system.
Excuse me, I’ve worked with various JS-based projects on both front-end and back-end in different teams. We all did TDD and ATDD, and we’ve never written these "type-system-substitute" tests.
Instead, we’ve tested only behavior from the user perspective.
In these codebases, I’m pretty sure, there are few functions here and there, that would behave incorrectly if you were to call them with e.g. a number instead of a string argument. But that is not a problem because nobody does that, because there are higher-level acceptance tests (e2e + integration) that ensure that behavior is consistent.
So the "in theory, but in practice" argument kind of doesn’t stand. At least not in my view of the world and experience.
I'm sure that tests have little to do with static or dynamic typing, or statically proven languages. Every corner case or circumstance that your function can be called in should be tested. It is true, however, that in dynamic languages there are more circumstances under which you function can be called. I don't find it a significant difference, though.
As of statically proven languages, the only difference is that your tests don't need to run - but they need to exist.
Having said that, after working with C++ for 15+ years, I now value dynamic typing for it will not break your whole build if some detail does not work correctly or is not yet implemented - especially the last part is valuable, IMHO. You can write the code that calls your function before having written it at all, and still execute the rest of your tests. Feels good for gradually turning tests green.
(The last part of my comment is still a detail and personal preference, though!!)
I agree with this ONLY if we’re talking about a library that is exposed to any user out there potentially.
If we’re talking about the application code where the team has full ownership of the full stack (as it should be), then there is no need to be testing the function how you do not expect to be called (but it could be potentially).
That’s because you’re not writing a function in isolation, it is part of one or multiple code paths of a bigger size. Potentially several layers of architecture, and if e.g. your business domain code is calling this function only with strings (and it would be absolutely non-reasonable to call it with something else), why should you spend your time and time of everyone else in the future (when running test suite) on testing what will happen if you pass a number (or anything else)?
When you have higher-level tests, that check what happens when multiple components and layers are integrated within various user/business acceptance scenarios, you’re going to confirm that function indeed is called properly at all occasions (implicitly).
Of course, if you don’t trust your team members to do the right thing, then you should work on that trust issue, find its root cause(s) and work through fixing it. Please, don’t fix people problems with technological complexity.
You're totally right. The statement came out a bit too pedantic, and yes, I was thinking more of code used by a wider audience. Because, from my usage experience of libraries in dynamic languages, I've learned that it is very frustrating when you accidentally passed in the wrong type, just to get seemingly random error messages four calls down the stack. And that partly confirms @combinatorylogic 's statement "most of the tests for the primitive dynamically typed languages are nothing but a poor men substitute for a type system.", although, as I said, I don't think that the tests that do substitute a type system are too much of a burden.
Again, I'm talking about widely used code here, not your team's shared libraries where you can tap the original author on the shoulder to get help with it if it spills out gibberish error messages.
You're doing it the right way then, good! I'd always take integration tests vs. any amount of unit tests. The problem is with all the people who perceive weak typing as an invitation to write tons of pointless unit tests, I'm sure you've seen it happening a lot.