Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
UI testing, Usability testing, Accessibility testing etc are not limited to BDD nor is necessary to follow BDD to bring them on a project, be that TDD, BDD, ATDD, whatever other bunch of uppercase characters glued together or none of them.
And of course we've logic living in the frontend that does belong to this context and needs to be unit-tested as well if you want to build confidence in your code.
Normally I'd agree with you, if it wasn't for the fact of that we built this without a single unit test in our frontend code. I suspect it's several orders of magnitudes more complex than what the average enterprise software developer has ever created ... ;)
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I also built complex codebases without testing by client decisions (which I find wrong and later issues proved me right), all of them being on the market up and running.
Glad I'm not the one maintaining it.
Btw your link sends me to a 404 inside GitHub (private project or wrong link) so I can't evaluate the complexity.
Even that a successful development is not proof for anything.
There's a high probability you still find issues in the future when adding more use-cases to pre-existing features or features that are dependant on them.
You can solve or spot them on any stage before production but it will be by manually testing.
You just didn't automate the tests, but you are still testing it by hand which is not the smartest move and you'll notice it the first time a bug appears in production.
Adding a console.log is testing (that some variable has some value), adding server logs is testing, checking the UI manually is testing as well. The question has never been to test or not to test. The question is on how you test.
The above thing seriously doesn't have enough logic in the frontend to justify creating unit tests for it, which might come as a surprise if you see its features, and/or try it out ...
Of course, it's built upon the same thing we've got 1,000+ unit tests in the backend for ...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Sorry I'm on the phone and hit send too early, edited the comment before 😅 (and now checking your link)
Edit:
Yup, this client code is really short, it can probably avoid most logic that a usual webapp has plus with some more E2E (apart from those sanity checks I saw) you'll cover it entirely or mostly like it was BDD.
I think we can agree that it's not the case of an usual webApp in which you'll have logic about what someone can see depending on it's role/permissions, multiple user journeys depending on X or Y, sometimes A/B testing (being created in-house or by some third party tool), content based on user preferences and so on. (Some of those needs to be double-checked by the backend of course, but the double is not silent).
Avoid testing on this situations can become a mess quickly. And even if it doesn't, my experience says that you'll get a hard time with what HHRR people categorises as "retaining the talent" 😂
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
UI testing, Usability testing, Accessibility testing etc are not limited to BDD nor is necessary to follow BDD to bring them on a project, be that TDD, BDD, ATDD, whatever other bunch of uppercase characters glued together or none of them.
And of course we've logic living in the frontend that does belong to this context and needs to be unit-tested as well if you want to build confidence in your code.
Normally I'd agree with you, if it wasn't for the fact of that we built this without a single unit test in our frontend code. I suspect it's several orders of magnitudes more complex than what the average enterprise software developer has ever created ... ;)
I also built complex codebases without testing by client decisions (which I find wrong and later issues proved me right), all of them being on the market up and running.
Glad I'm not the one maintaining it.
Btw your link sends me to a 404 inside GitHub (private project or wrong link) so I can't evaluate the complexity.
Even that a successful development is not proof for anything.
There's a high probability you still find issues in the future when adding more use-cases to pre-existing features or features that are dependant on them.
You can solve or spot them on any stage before production but it will be by manually testing.
You just didn't automate the tests, but you are still testing it by hand which is not the smartest move and you'll notice it the first time a bug appears in production.
Adding a
console.logis testing (that some variable has some value), adding server logs istesting, checking the UI manually is testing as well. The question has never been to test or not to test. The question is on how you test.Oops, sorry, wrong link - Edited it now ...
The above thing seriously doesn't have enough logic in the frontend to justify creating unit tests for it, which might come as a surprise if you see its features, and/or try it out ...
Of course, it's built upon the same thing we've got 1,000+ unit tests in the backend for ...
Sorry I'm on the phone and hit send too early, edited the comment before 😅 (and now checking your link)
Edit:
Yup, this client code is really short, it can probably avoid most logic that a usual webapp has plus with some more E2E (apart from those sanity checks I saw) you'll cover it entirely or mostly like it was BDD.
I think we can agree that it's not the case of an usual webApp in which you'll have logic about what someone can see depending on it's role/permissions, multiple user journeys depending on X or Y, sometimes A/B testing (being created in-house or by some third party tool), content based on user preferences and so on. (Some of those needs to be double-checked by the backend of course, but the double is not silent).
Avoid testing on this situations can become a mess quickly. And even if it doesn't, my experience says that you'll get a hard time with what HHRR people categorises as "retaining the talent" 😂
All of these, and more, is to be found in Magic ... ;)
Created prograMagically I guess 😁
Hehehe :D
Yup!! ^_^