I must agree with you. In real time developers work on different projects. The clients donot want to pay for testing. So, when a feature is done, if the developer does not have a task called feature/unit tests he will start working on other tasks or projects. Many authors speak / write about ideal situations when developers have time and tasks to make unit/feature tests. In many companies, it is not true. We know what an ideal situation is, but real life is something different.
I also quite disagree with the pest approach. Pest makes the tests code not OOP enough and so far I don't see a lot of advantages. I worked with it a lot, btw
I really like this kind of 'react' content, because we have double bang for the buck. We get to know other peoples opinions, through the lensing and filtering of your experience. So is a lot 'safer' to consume the content.
I'm fully against promoting feature tests over unit tests. If testing features (routing->middleware->permission->validation->logic->data->view) is the most important thing in the app, then it should be a cruddy app. If it isn't possible to get the needed test value by just testing the logic, then the app architecture should be questioned.
Thanks for reviewing and sharing your feedback.
I must agree with you. In real time developers work on different projects. The clients donot want to pay for testing. So, when a feature is done, if the developer does not have a task called feature/unit tests he will start working on other tasks or projects. Many authors speak / write about ideal situations when developers have time and tasks to make unit/feature tests. In many companies, it is not true. We know what an ideal situation is, but real life is something different.
When I work on client projects I don’t ask time for testing its part of the task.
The more you test the quicker you will become at it.
I also quite disagree with the pest approach. Pest makes the tests code not OOP enough and so far I don't see a lot of advantages. I worked with it a lot, btw
When doing automated deployment, you can set it up to only deploy on, for example, a new git version tag, so that it ignores other cases.
I really like this kind of 'react' content, because we have double bang for the buck. We get to know other peoples opinions, through the lensing and filtering of your experience. So is a lot 'safer' to consume the content.
The name is: the Povilagen
First of all, thank you for advicing such a great collegue!
Some people say that you shouldn't fake http requests from outside sources (e.g. API) when testing, but use the actual live source.
This would be an integration test
I'm fully against promoting feature tests over unit tests. If testing features (routing->middleware->permission->validation->logic->data->view) is the most important thing in the app, then it should be a cruddy app. If it isn't possible to get the needed test value by just testing the logic, then the app architecture should be questioned.
You would be surprised how many projects are actually cruddy or can be viewed as cruddy