In my last post I talked about ideas for convincing devs to do more testing. However, perhaps what I should have addressed is the topic of why do d...
For further actions, you may consider blocking this person and/or reporting abuse
Hi, Acceptance-Tests is what you are looking for. :)
e.g. via codeception.com/
Thanks for picking me up on this 🤣 I don’t disagree with you. Deciding what to test and at what level is one of the hurdles that trips people up. Overtesting is a serious problem. For unit tests I usually avoid testing anything ”static” like HTML or CSS. Those are tests that I’d rather leave to QA, or write up as system/acceptance tests in some other way.
To come back to my statement... yeah, there’s a huge assumption hidden within it, I‘ll see if I can find a way to make that clearer, as discussing how to test well is waaaay beyond the scope of this post 🤗
Does this really exist? I would be interested in hearing some examples. 🙏
I can definitely see a problem in time spent in testing. And that is most likely spent in manual testing because of not having knowledge on how, on what level and what exactly to test.
Thanks for a great post! 🍻
It might be something I’ve just dreamed up, or maybe there’s a better name for it, but here’s how I think of overtesting.
Overtesting is what happens when your write tests that cover more surface area than necessary. One way this happens is relying on end-to-end tests instead of unit tests. Greater surface area means more chance for tests to break when code is changed. In other words, you get brittle tests.
Hopefully that makes sense?
Each test is additional code which must be maintained. If the tests need to be updated with every code change, even though the functionality they are expecting to test isn't changing, it becomes a liability.
Clearly that isn't because there are too many tests, but it kind of is. The mantality this come from is that every test is valuable. While you could write another test, clearly this is covering more and may find an issue it just isn't this time.
It makes!
I think this is due to focusing the tests on the wrong level.
Too small or inappropriate details are verified in a test that is done by eg. Calling the service over HTTP.
Thanks I quite agree with you.
In my current job, I often am the only dev front-end, with no QA (what's this ?? not sure that my manager even know the term) so I have learned to appreciate a lot TDD and testing.
But while I am getting better at unit testing, I still have a lot of difficulties understanding the methodologies, like how to correctly use mocks, or the functional and e2e tests. It really is a whole part of the job, I just don't have the time and ressources currently to learn it (and of course, no one to learn it from) so I am sticking to unit testing, for the moment, until I can learn more.
If someone has good ressources on the subject, I would thank you for it
The best way to learn (IMHO) is to work with others who REALLY know how to do it. I had been doing what I thought was TDD for 5 years before I joined a TDD consultancy. I was lucky to have colleagues who helped me improve. So if you get the opportunity to pair with experienced TDDists then I suggest you take it. You’ll learn so much. One way may be to join a local coding dojo meetup or software crafter meetup if you can find one (see softwarecrafters.org).
Since you’re a front-end dev, you might also be interested in my book, Mastering React Test-Driven Development. It covers unit testing and also acceptance testing with Cucumber and Puppeteer.
Thanks a lot :)
I probably will buy your book (today, before Brexit XD) It seems exactly what I need thanks. At it probably will help in my company
This. Our QA often thinks of scenarios I would miss. She's the heroine of this story.
Does that imply that we should offload all of our testing effort to QA's? No
Yes, please don't dump your buggy code onto QA because you think it's their job to find problems. What I was trying to say is that I learn new things to look for every time QA finds something.
End-to-end test for success path if there`s no complex logic.
Separate QA for checking that code works is anchor that slows down processes.
Statement above is about unit-tests.
Agree with you, but getting it to the habit of other team members is a long shot. I am trying to guide by example and hoping some day unit tests with high coverage would be the requirement instead of optional.
We require tests as part of revisions (think Pull Requests) in our company workflow, and they're reviewed as part of the code accordingly. If you don't know how to write good tests, learn how. ;)