STOP WRITING CRAZY FUNCTIONS FULL OF INSTANTIATIONS THAT I NOR ANYONE WILL EVER BE ABLE TO WRITE UNIT TESTS FOR!!! STOP calling static factory methods that spawn up who knows what in mid function as if Im actually going to be able to mock such a dependency. Better yet, practice test driven development so we don't end up in this mess again

  • 2
    Agreed, or those people that 'write tests later'
  • 1
    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)
  • 0
    This is why eating your own dog food.
  • 4
    Headless chrome, selenium.
  • 0
    That ^ 👍👍👍
  • 3
    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.
  • 1
    I 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.
  • 1
    @mr-user run JavaScript from selenium, you are running a browser at the end of the day.

    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.

  • 3
    @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🤔
  • 2
    @PublicByte so... shove a user in front of it instead?

    With that logic I'll just start saving changes in prod again.
  • 1
    @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.
Add Comment