re: Is JavaScript the most confusing programming language? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 w...

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!!)

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.

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.

code of conduct - report abuse