Introspection APIs #366

Activity

1. brarcher commented on Jun 25, 2026

   

   brarcher

   on Jun 25, 2026

   Contributor

   More actions

   Sounds interesting!

   I'm not that familiar with using XCode. If you think adding introspection APIs would enable running unit tests and mapping the results to source code in XCode, give it a try. As long as other supported platforms for Check work just fine too it should be ok.
2. eschaton commented on Jun 25, 2026

   

   eschaton

   on Jun 25, 2026

   CollaboratorAuthor

   More actions

   Thanks! Xcode (lowercase "c") is an IDE so in addition to editing and building your code, it also has features like presenting the results of tests and running both all and a subset of tests or an individual test for rapid iteration scenarios like test-driven development.

   Adding full support for Check to Xcode would require participation from my former coworkers in Xcode engineering, since Xcode doesn't expose that kind of plug-in API. However, because Xcode's testing framework, XCTest, is written in a dynamic OO language (Objective-C), I can add a substantial amount of support for reporting test results and making it possible to re-run tests after they've run once as long as I can actually introspect the structure of the tests before they've been run.
3. eschaton commented on Jun 26, 2026

   

   eschaton

   on Jun 26, 2026

   Last edited by eschaton

   CollaboratorAuthor

   More actions

   Here are the APIs that I think would be useful for this:

   size_t srunner_nsuites(SRunner * sr);
   Suite **srunner_suites(SRunner * sr);
   
   const char *suite_name(Suite * s);
   size_t suite_ntcases(Suite * s);
   TCase **suite_tcases(Suite * s);
   
   const char *tcase_name(TCase * tc);
   size_t tcase_ntests(TCase * tc);
   TTest **tcase_tests(TCase * tc);
   size_t tcase_ntags(TCase * tc);
   const char **tcase_tags(TCase * tc);

   They should be self-explanatory; the tags APIs aren't something I'd use in Xcode integration, but I could see someone else wanting them and included them for completeness. The string-returning APIs return pointers into Check-managed memory, the array-returning APIs return newly-allocated arrays that need to be freed with free(3) but whose contents don't need to be, just like with srunner_results().

   I also wonder if the result of tcase_tests() should be an array of TTest * or of some other struct that can be interrogated for its associated TTest * and its signal, iterations, etc., basically the parameters to _tcase_add_test() that get packaged into the TF that's actually part of tc->tflst. Maybe exposing TF, opaquely with accessors, would be the right thing for the array returned by tcase_tests()?
4. brarcher commented on Jun 27, 2026

   

   brarcher

   on Jun 27, 2026

   Contributor

   More actions

   I think the APIs sound reasonable. Regarding tcase_tests(), what's returned should have some path to getting at the other details like you brought up (signal, iterations, etc). Exposing TF could work with some additional helper methods could work.
5. eschaton

   added the

   Feature

   issue type on Jul 2, 2026
6. eschaton

   self-assigned this

   on Jul 2, 2026
7. eschaton

   added

   enhancement

   on Jul 2, 2026
8. eschaton

   linked a pull request that will close this issueWIP: Introspection APIs (#366) #378on Jul 3, 2026
9. eschaton commented on Jul 3, 2026

   

   eschaton

   on Jul 3, 2026

   CollaboratorAuthor

   More actions

   I figure exposing TF with the additional helper methods is the way to go. I also think changing tcase_name() to return the name of the given case (instead of taking no argument and returning a current name) is a reasonable and straightforward API change, if I also add a tcase_current().