When you wrote code for tests you need to know what output is produced from given input. So if you can identify parts of code that work without dependencies (for example without calling the database and checking the results), you can easily test them. The more dependencies your code has (for example on external microservices) the more you have to mock. And if you mock too much, you will end up with code that has pretty high coverage but still the program will be full of bugs.
You have existing codebase, you you should start from parts which are easiest to understand, totally not partially. Controllers are pretty bad choice because they span lots of logic spread across multiple modules. In the other hand, smaller models should be simpler, because they don't depend on other modules (for example only on the database which you should mock).
Look, my project is a frontend over some kind of analytical database, I have no control of the data I'm processing. My application has coverage of about 90% with single API call. That single tests shows that my application can connect to the database, fetch the data, process it, and present, yet we still have tons of problems, for example the title is missing here and there. The thing is, the title comes from external data and I can't do anything about it. If I had a test that will check that for given keyword all articles have tiles - this test will be meaningless.
What I can do - is to do opposite approach. Mock the data and test my applications logic (assume that the title is provided, and put error handling when it's not). Check that connection can be retried when timeout happens. Unfortunately this requires lots of mocking.
Most of the tests in my application focus on checking if the user input is producing correct database queries. The query building logic is done by few classes, all of them have no dependencies. I made them that way, so that is easy to test them. I choose to do that under influence of "functional paradigm" (something different than object oriented programming).
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.
When you wrote code for tests you need to know what output is produced from given input. So if you can identify parts of code that work without dependencies (for example without calling the database and checking the results), you can easily test them. The more dependencies your code has (for example on external microservices) the more you have to mock. And if you mock too much, you will end up with code that has pretty high coverage but still the program will be full of bugs.
You have existing codebase, you you should start from parts which are easiest to understand, totally not partially. Controllers are pretty bad choice because they span lots of logic spread across multiple modules. In the other hand, smaller models should be simpler, because they don't depend on other modules (for example only on the database which you should mock).
Look, my project is a frontend over some kind of analytical database, I have no control of the data I'm processing. My application has coverage of about 90% with single API call. That single tests shows that my application can connect to the database, fetch the data, process it, and present, yet we still have tons of problems, for example the title is missing here and there. The thing is, the title comes from external data and I can't do anything about it. If I had a test that will check that for given keyword all articles have tiles - this test will be meaningless.
What I can do - is to do opposite approach. Mock the data and test my applications logic (assume that the title is provided, and put error handling when it's not). Check that connection can be retried when timeout happens. Unfortunately this requires lots of mocking.
Most of the tests in my application focus on checking if the user input is producing correct database queries. The query building logic is done by few classes, all of them have no dependencies. I made them that way, so that is easy to test them. I choose to do that under influence of "functional paradigm" (something different than object oriented programming).