Usually design team can define enumerations for different useful data types and values.
In many cases, those enums can be found very useful also in the testbench.
Should verification team use the same enums for their job (taken as is from the design RTL) or re-define them and maintain them in parallel in the verification environment?
I think there might be a number of opinions on this and you might have to evaluate this on a case by case basis. If the enumerations come from some external standard then it probably makes sense to share those definitions. You’ll have to look at what errors could be introduced by sharing the same definitions like a mistake in encodings.
There are cases where it’s really nice to do this. However, when sharing something like this, it still needs to be verified somehow. Might need some kind of formal code review with design, dv, and architects. Then changes need to be tightly controlled.
Just use it!
I think DUT, which comes from design team, is dominant and TB is secondary.
So as a verif engineer you should try to use as much as possible DUT terminology.
This will help you to maintan your TB also easily communicate with design team.
However sometimes you need to override or add more enums in design team code. Than you can use TB_* prefix for always recognize your defines.
But general rule ( my opinion) to remember - DUT is dominant, TB is secondary. Customers pay for DUT not for TB.
So try always use DUT items in your TB