You are my hero

@noomorph sorry for repeating myself, but really - do we really need to keep jasmine as 'legacy'? Can we not just deprecate in a major version and move on?
Doing so would also enable you to remove all of the hackish part of init/cleanup code you recently added in the Detox wrapper, won't it?

@d4vidi, I really really want to rewrite adapter in a very breaking manner, so I would go an extra mile postponing a major release to not breakchange two times in a row, with jasmine and with adapters.

P. S. Actually this time I plan to kill adapters. No adapters anymore. This will become a major version.

P. P. S. The problem is that you will be very hesitant to review extra 500 lines of code in a single pull request, most likely, if I continue adding changes to here, so that's why I considered splitting into two PRs.

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.
For more information on bots in this reporsitory, read this discussion.

Pull Request Test Coverage Report for Build 2282

• 158 of 180 (87.78%) changed or added relevant lines in 12 files are covered.
• 2931 unchanged lines in 118 files lost coverage.
• Overall coverage decreased (-5.3%) to 73.429%

Totals
Change from base Build 1221:	-5.3%
Covered Lines:	9502
Relevant Lines:	13001

💛 - Coveralls

@noomorph I still see there is no documentation re the huge change in #2027, just making sure its going to be a part of this PR.

@rotemmiz, that's right, because #2027 was being treated as a part of this one. I will be working on the docs today. I am not bananas not to supply such PRs without docs, hehe, don't worry.

I'll ask you to review user-facing places on Sunday.

This is so important, we should have done this kind of thing a long time ago, tapping in at the configuration space instead of the user space.
Can you please clarify regarding point no 2, why would this type of setup disregard the module cache?

• side note -

Initiate Detox as early as possible, even before we know what tests we are going to run.

That would also enable a fix for #2097, as the device's platform would already be known before it calls register tests

• Documentation: Need to update the whole setup process - We should prefer jest over mocha and make it the 1st-class solution in our description.

With this new integration with jest-circus. How should I launch the app with the permissions I need?

I got my tests working again by overriding the initDetox function in my CustomDetoxEnvironment like this:

  async initDetox() {
    const instance = await this.detox.init(undefined, {launchApp: false});
    await instance.device.launchApp({permissions: {notifications: 'YES'}});
    return instance;
  }

Is this the best way to define permissions for my device?

@wlindner, at the moment, not much time has passed since this feature entered production; hence I can't say for sure what the best method is.

Alternative approach

In one of our projects, we apply another approach since the initialization phase is more complicated, e.g., starting a mock server and some CI preparations.

detox.config.js

module.exports = {
  // ...
  behavior: {
    init: { launchApp: false },
  },
  // ...
};

init.js

beforeAll(async () => {
  // launch mock server and other stuff
  await device.launchApp({permissions: { /* ... */ }});
});

jest.config.js

module.exports = {
...
+  setupFilesAfterEnv: ["./init.js"],
...
};

Pros and cons

initDetox()

Pros. If you keep all your initialization steps in the protected initDetox, then in case if the app cannot start correctly, the failure phase is going to be much shorter and cleaner - for example, at the moment, Detox simply skips all the tests and promptly exits with a failure.

Cons. Any potential timeout errors of initDetox() are handled by handwritten wrapper functions (bypassing Jest timeout mechanisms), and there's a chance you might have sometimes subpar experience in unstudied aspects (use with sourcemaps, etc). Also, although there is no intention to break initDetox(): Promise<Detox> signature, I cannot give guarantees either that its signature won't undergo some changes later.

beforeAll

Pros. The beforeAll hook approach looks a bit cleaner and totally in line with both the Jest and Detox approaches and less dependent on our recent semi-documented initDetox and cleanupDetox virtual methods.

Cons. Most likely, if you have SpecReporter enabled, you'll have a bit more messy and verbose output if there is a failure in the very beginning. If your setup is very simple, you might feel that it is redundant to create one more file and add it to setupFilesAfterEnv, but that's a purely aesthetical reason with no practical reasoning underneath.

Conclusion

Try out beforeAll approach, if this is acceptable for you.

If you nevertheless prefer overriding the initDetox protected method, your code excerpt looks valid to me, thus you are free to do that either.