When something is difficult to test, sometimes it's because of the design approach. The flawed approach could be in the design of the test or in the design of the production code. In this case, it may be a little of both but I would start by re-evaluating the test design approach.
Should any of the existing enum values be treated as unexpected by the eSF.filter() method? Or are you simply trying to safeguard existing code from breakage in the event that someone changes the ImportT enum in the future? If this is your motivation, then here's my approach: Since an enum represents a set of well-known values, then write a test that will break if the number of enum values changes. Add a note in the test to tell the developer what to do if it breaks.
You would add this test to any test class that references the enum type so that the design of each class that is dependent on the enum type will have to be re-evaluated against the new set of enum values if someone changes it in the future.
In this case, the test is there not so much to verify functionality of the production code but to serve as an "alarm" that will go off if any of your current assumptions is invalidated by a change in the production code.
BTW, the enum values you have defined are very cryptic. Prefer enum values that are more descriptive.