Generally speaking, development time that is overly spent in test code rather than in production code can be a sign of poorly designed or crafted tests. A feature that is being implemented or changed will cause some tests to fail. How fast can the test code adapt? How many occurrences of test data or functionality are there that need to be changed? How easy is it to add test cases to the existing code base?

Failing tests that are being @Ignored for more than a very short period of time are also an indicator of a potential flaw in test quality. If the test case is logically still relevant, it needs to be stabilized and fixed. If it becomes obsolete, it should be deleted. However, tests should never be deleted in order to save time and effort that would be necessary to fix them when the test scenarios would logically still be relevant.

Copy and pasting test code should also be an alarming signal. This practice is sadly quite common in enterprise projects, especially when test scenarios slightly differ in their behavior. Copy and pasting violates the don't repeat yourself (DRY) principle and introduces a lot of duplication which makes future changes expensive.