When they break (which does happen once in a while), someone usually fixes them within a few minutes. The tests are always green on this main development branch. We maintain one main development branch for IL2CPP, which always tracks the leading edge branch for development in Unity as a whole.

If all of these tests are green, then we feel confident that we can ship IL2CPP at that moment. Here are the number of tests we current have a each level (I’ll discuss what each type of test actually is below). The various types of tests that we run against the IL2CPP code base break down into a few different levels. By scoping down the space of possible causes of a given bug this way, we can correct bugs much more quickly. Troubleshooting: Since the code in IL2CPP behaves as we expect it to, bugs are almost always unimplemented sections of the code or cases we have not yet considered.If the tests pass, it is very unlikely that a regression has been introduced. Confidence: Most changes to refactor code in IL2CPP can be made with high confidence.As a development team, this test suite provides two important benefits. This process helps to drive the design of IL2CPP, but it also provides the development team with a large bank of tests which run rather quickly and exercise nearly all of the existing behavior in IL2CPP. Most of tests are written before production code, and these tests always need to fail in an expected way before the code to make them pass is written.

Since IL2CPP has a finite (although rather large) set of inputs - the ECMA 335 spec- the process of developing it fits nicely with TDD concepts. Much of the code for IL2CPP is written using the practice of Test Driven Development (TDD), and very few pull requests are merged to the IL2CPP code without significant test coverage. The IL2CPP team has a strong test-first development mentality.

Il2cpp source code