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.

  • 0
    It's pretty ironic. I write testable code but don't test it.
  • 0
    I consider selenium web driver and all the other crap as hacky workarounds that will, without a doubt, fail in different environments.
  • 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🤔
  • 0
    I think user testing is useful for bug regressions of rather complex frontend related stuff but god no, don't you dare to test everything.

    Testing everything's a huge waste of time. In the next project, you might want to look at what type of user tests actually helped you instead of implementing all those brain dead tests with very obvious actions.

    At the end of the day, you're wasting company funds implementing plain obvious tests that might not fail in the entire lifespan of the project.
  • 2
    @PublicByte so... shove a user in front of it instead?

    With that logic I'll just start saving changes in prod again.
  • 0
    @C0D4 that's your problem then if you can't estimate if "that one test case" could help someone.

    > Shove a user in front of it instead?

    That and a QA guy. They'll find edge cases you didn't thought about. Your user tests aren't going to magically test every behavior.
  • 2
    @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.
  • 0
    @C0D4 fair enough.
Add Comment