Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Agreed, or those people that 'write tests later'
How do I write unit test if I need a browser environment? Except for test scripts that will automate UI clicks (e.g. press Import button and give specific file)
This is why eating your own dog food.
That ^ 👍👍👍
Backend : TDD with use case scenarios not coverage, you can write 100% coverage and still not test the damn thing.
Frontend : BDD, understand how your users actually use it, and write your tests in selenium accordingly.
Together: if it manages to break you'll find it.
mr-user14761yI thought testing user interface is black magic.
Testing user interface is a nightmare. I only separated the user logic and just test that logic. How can you test that the table is actually scroll or button color is changed in test?
Maybe that why I am getting the user interface based bug.
You could use scroll into view once you have identified the element.
So if you have a div with a scroll bar containing the table, the div would scroll across and bring the selected cell into view.
@PublicByte I'm curious how selenium is a hacky work around, and what you consider using instead, since based on that comment I can't write user tests with a browser... that replicates what a user would do🤔
@PublicByte so... shove a user in front of it instead?
With that logic I'll just start saving changes in prod again.
@PublicByte they're not suppose to test every scenario though.
They should be covering the standard and complex scenarios that a user should be doing every day.
Edge cases will always appear and are generally caused by users who enter the wrong data or select the wrong option in a pick list which is not something you can always control systematically, it's not like you can force a user to type there address correctly, let alone get the country right no matter how many chances you give them to review it.
By covering the standard workflows, you can have a level of confidence that changing a feature won't introduce any critical side affects to the end users, and your right, a QA should be testing it and finding issues you as the dev haven't thought off but having the test scenario's in place means a user doesn't need to regress every pathway over and over again.