Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best way to wait for adapter stop? #507

Open
klein0r opened this issue Jun 25, 2022 · 5 comments
Open

Best way to wait for adapter stop? #507

klein0r opened this issue Jun 25, 2022 · 5 comments
Labels
enhancement New feature or request

Comments

@klein0r
Copy link

klein0r commented Jun 25, 2022

I have a schedule adapter and I want to perform some checks when everything is finished (based on adapter configuration). What is the best way to wait for the adapter to stop?

Something like this?

'use strict';

const path = require('path');
const { tests, IntegrationTestHarness } = require('@iobroker/testing');
const chai = require('chai');
const expect = chai.expect;

// Run integration tests - See https://github.com/ioBroker/testing for a detailed explanation and further options
tests.integration(path.join(__dirname, '..'), {
    defineAdditionalTests({ suite }) {

        suite('Test', getHarness => {
            /**
             * @type {IntegrationTestHarness}
             */
            let harness;
            before(() => {
                harness = getHarness();
            });

            it('Should work', function (done) {
                this.timeout(60000);

                harness.startAdapterAndWait()
                    .then(() => {
                        expect(harness.isAdapterRunning()).to.equal(true);
                        expect(harness.isControllerRunning()).to.equal(true);

                        // Wait for adapter stop
                        return new Promise(resolve => {
                            harness.on('stateChange', async (id, state) => {
                                if (
                                    id === `system.adapter.${harness.adapterName}.0.alive` &&
                                    state &&
                                    state.val === false
                                ) {
                                    resolve(true);
                                }
                            });
                        });
                    })
                    .then(() => {
                        console.log('-----------------> STOPPED NOW');

                        done();
                    });
            });
        });

    }
});
@klein0r
Copy link
Author

klein0r commented Jun 25, 2022

It would be awesome if the test lib provides a function with a promise which waits for stop and checks the allowed exist codes to resolve the promise. Like

harness.startAdapterAndWaitForStop()
    .then(exitCode => {
        // ...
    });

@AlCalzone AlCalzone added the enhancement New feature or request label Jun 27, 2022
@AlCalzone
Copy link
Collaborator

I don't think this was a use case before, so it wasn't considered yet. Currently a suite essentially ends when the adapter stops.

@klein0r
Copy link
Author

klein0r commented Jun 27, 2022

I've migrated some testing logic to the integration tests for iCal. See https://github.com/iobroker-community-adapters/ioBroker.ical/blob/062b64f3555f40fb0c523f260ae126e0c2cf0759/test/integration.js

But I don't know if this is the best way to do it. At the moment the adapter is started with given settings in the "before" section and returns a promise which will be resolved when the adapter has been stopped. After that, all states can be checked.

@AlCalzone
Copy link
Collaborator

This

                            expect(harness.isAdapterRunning()).to.be.true;
                            expect(harness.isControllerRunning()).to.be.true;

is unnecessary IMO, since startAdapterAndWait will resolve as soon as the above is true.

The rest with the waiting looks like a viable workaround, although it is a bit awkward. I'll look into making this feel more "natural".

@klein0r
Copy link
Author

klein0r commented Jun 27, 2022

although it is a bit awkward

That was the reason for this issue 😄 Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants