The answer is mostly yes, but it depends.
In an ideal world, you would run the tests in DEV. In general, the earlier you can run tests, the faster you can fix issues that arise, and the faster you can develop. It's more difficult to fix a problem 3 weeks after you stopped working on it and have moved onto something else.
However, testing isn't always free. Even with automated tests, it takes effort to maintain them even if running them doesn't take as much effort. This is especially the case in shared environments with e2e tests (which I assume you're talking about since this question is tagged e2e-testing). State mutation is a big hassle to deal with in these sorts of persistent environments.
Here's a few questions I would ask myself in your situation:
- Is everything that is deployed to DEV supposed to be working with other components?
- If yes, then you should definitely be running tests on DEV.
- What is causing the majority of the test failures you're seeing?
- Are developers making useful changes when test failures occur in DEV?
- If yes, then you should keep running the tests on DEV
- Are the failing tests exposing failing dependencies between parts of the larger system?
- How long is it between deploying to DEV and TEST?
- If this delay is too long, then you need to either shorten the delay or continue to run tests on DEV. Though of course, both is best.
- Are the developers writing/updating tests for their stuff after it's deployed to DEV?
- If so, why not before? That would help prevent test failures in DEV and ensure that when they say work is finished, it's actually finished (your team's Definition of Done factors in heavily here).
Also, as a side note, you might want to check out the Software Quality Assurance Stack Exchange if you have more questions about testing in general.
