It's safe to say that testing in the front-end world has grown over the past five years.
Jest has stolen the scene in the unit testing world, earn...
For further actions, you may consider blocking this person and/or reporting abuse
I agree with the spirit of the post, essentially the best code is the code that's never written. That said, I think we're missing the point to testing: the power it gives us to shape our code by writing our tests before each small piece of production code. In other words, TDD.
I would argue most of the value of tests isn't in validating the that our software still works. That's just a fantastic side-effect. The real point to writing tests is in allowing them to drive the design of our code. TDD forces you to write each function from the perspective of the person calling the function. It doesn't care about implementation details, instead it cares about the interface.
I'm still amazed at the difference in code quality between when I practice TDD and when I don't. It's huge. And the funny thing is TDD usually ends up taking me less time then not writing tests at all, considering all of the time it takes me to debug my untested code.
I totally agree with you. However, I feel that TDD should be used by developpers that are already experienced with the library/framework they're using. The reasoning behind this is that by writing their tests before hand, beginners often end up rewriting their tests when they realize that the library/framework doesn't behave as they have expected. And basically, this takes away precious time that they could have been invested in learning how to use the library/framework better.
This is a great point, thanks for sharing!
Are...are you trolling? Because I am flabbergasted.
I mean, it's one thing to have a healthy discussion around how much testing should be done, or what type of tests should be written, or what parts of an app should be tested. But you are suggesting zero tests. If you are building a prototype for validation, sure that's fine because it's not a real app and people using it know that its not real. But as I read this you are suggesting that people should deploy a production system for real people to use without any tests, YOLO style, because you need their feedback before you can solidify your design. And that is bonkers to me.
I hope to the FSM that your app doesn't do any sort of e-commerce, or authentication, or take user input of any kind.
I don't think Kevin's suggesting zero tests, but rather meant it as avoid pre-maturely writing tests.
Like when you haven't figured out if people want what you are building, don't write those tests yet. I would even say, don't even build stuff before you validated that people want it - you can survey or show people mockups to validate demand first.
Like when you haven't gotten a firm grasps of your front-end stack, don't write those tests yet, because unit-tests like Jest can requires a fair bit of planning beforehand.
And like and when you've got tests that aren't connected to your pipeline, don't write more tests yet. Connect those existing ones first, before moving on the writing new tests.
Yes, this exactly!
Sorry I wasn't clearer in the post. Sometimes I end up having a lot written in my head that I forget to put down in the text.
When I read unit tests I think TDD-style unit tests.
Are those the kind of unit tests you are referring to?
The TDD-style unit tests are not created for the purpose of testing, they are created for the purpose of design. As a byproduct, having a suite of unit tests to ensure basic correctness and detect basic correctness regressions is a nice residual value.
TDD has a very strong stance to avoid writing unit tests pre-maturely. Rather it advocates just-in-time creation of unit tests, and not a moment before.
I'm not familiar with Jest. Probably would have been useful back when I was working in TypeScript.
I love the concept of TDD, but have found it applies more to server-side type scripts than front-end work. For front-end, there's a lot of user interaction embedded in the code, which can make TDD harder to practice (but not impossible).
Some of the most fun I've had writing code was building out a component TDD style. That said, the component had very little user interaction, but a lot of logic going on. It fit the bill perfectly for TDD.
Thanks for the response!
One of the big proponents of TDD is Robert Martin.
Robert Martin does not think user interaction (UI) part of a program is suitable for TDD, as per When TDD Does Not Work.
Just thought you might be interested. ;-)
You are right. I don't even think about writing them, and I have a buggy app for no reason I don't know why.