Focus on the user flows for your application. If it's a web app, that's your web app visitors. If it's a command line interface you develop, it's the users of that CLI.
For anything web based, look at cypress.io. To start, there's no need to fully automate end-to-end tests for each pull request - that's something to work on later. Start with running your test suite against a staging or even production environment ever hour or 30 minutes, depending on how often you deploy. Then try to automate that process so that the tests run automatically after each deployment.
Write unit tests for complex functions. Don't test get and set functions on classes. A solid, fast-running test suite of end-to-end tests is more valuable in my opinion than 100% unit test coverage with lots of mocked parts of the overall system.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Focus on the user flows for your application. If it's a web app, that's your web app visitors. If it's a command line interface you develop, it's the users of that CLI.
For anything web based, look at cypress.io. To start, there's no need to fully automate end-to-end tests for each pull request - that's something to work on later. Start with running your test suite against a staging or even production environment ever hour or 30 minutes, depending on how often you deploy. Then try to automate that process so that the tests run automatically after each deployment.
Write unit tests for complex functions. Don't test get and set functions on classes. A solid, fast-running test suite of end-to-end tests is more valuable in my opinion than 100% unit test coverage with lots of mocked parts of the overall system.