XCTest to test EndpointSecurity error，ES_NEW_CLIENT_RESULT_ERR_NOT_PRIVILEGED

Question

Created Sep ’24

Replies 3

Boosts 0

Participants 2

I tried to use XCTest to test my own project that uses EndpointSecurity, but when I created the esClient I got an error:ES_NEW_CLIENT_RESULT_ERR_NOT_PRIVILEGED, indicating that it was not root.

This makes it impossible for me to do coverage tests for the ESClient application. Is there any way I can implement this ESClient test? If so, how should I use it? The project is a macOS program, if I use gcov, but I find I can't get coverage. Using __gcov_flush will indicate that there is no symbol

    #if !TARGET_IPHONE_SIMULATOR
        NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
        NSString *documentsDirectory = [paths objectAtIndex:0];
        setenv("GCOV_PREFIX", [documentsDirectory cStringUsingEncoding:NSUTF8StringEncoding], 1);
        setenv("GCOV_PREFIX_STRIP", "13", 1);
    #endif

    extern void __gcov_flush(void);
    __gcov_flush();
#endif

Answered by DTS Engineer in 803542022

You’re not going to be able to unit test your interactions with Apple’s ES infrastructure. That makes sense because such testing isn’t unit testing; rather, it’s testing the integration between your code and Apple’s code.

IMO you need to split your testing into two:

Separate your code into units that you can test independently. These shouldn’t depend on the ES context.
For the code that integrates these units with the ES infrastructure, test that using an integration test.

I talk about this concept in more detail, albeit in a very different context, in Debugging a Network Extension Provider.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’24

Recommended

You’re not going to be able to unit test your interactions with Apple’s ES infrastructure. That makes sense because such testing isn’t unit testing; rather, it’s testing the integration between your code and Apple’s code.

IMO you need to split your testing into two:

Separate your code into units that you can test independently. These shouldn’t depend on the ES context.
For the code that integrates these units with the ES infrastructure, test that using an integration test.

I talk about this concept in more detail, albeit in a very different context, in Debugging a Network Extension Provider.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

DTS Engineer OP

Apple

Sep ’24

Please reply as a reply; if you reply in the comments, I may not see it. See Quinn’s Top Ten DevForums Tips for this and other titbits.

How should I implement constructing a fake es_message_t here.

IMO you shouldn’t. Rather, have your core code work in terms of its own abstractions then:

Implement those abstractions on es_message_t in production.
Implement them internally for testing.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

c4m3l OP

Sep ’24

The method I use now is to forge the es_message_t object, so as to verify the corresponding relevant code logic through XCTest and carry out coverage statistics. However, some operation functions of the es_message_t object may not be directly called, which will cause crash.

0