Data beans never set back up during integration testing using Swiz

[Brian J]

Hello, I work on a project which uses Swiz for dependency injection and we have a BeanProvider type created which I use to construct the Swiz context in a superclass test case that tests all of our beans in that BeanProvider.  The team defined one of them as a DatabaseManager, which uses and opens a flash.data.SQLConnection to a SQLite store in the Windows temporary directories.  After this, various DAOs have this DatabaseManager injected into them so they can use the connection to run their queries.

However, sometimes on startup and also very sporadically during integration testing (lots of values of org.fluint.sequence.* floating around various [Test(async)] functions), the app raises the following error:

Error #3104: A SQLConnection must be open to perform this operation

Anyone can predict the randomness of this occurring, since it invariably randomly occurs.  Without knowing too much about the framework itself, what would cause this? Does this happen because of something to do with tearing down beans in the [After] functions?

[Brian Kotek]

It would really depend on what the operation is and when it is happening. It sounds like a timing issue to me.

--
You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiz-framewor...@googlegroups.com.
To post to this group, send email to swiz-fr...@googlegroups.com.
Visit this group at http://groups.google.com/group/swiz-framework.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian J]

What other sorts of information would you require to help identify the issue?

[Brian J]

We defined a PostConstruct and PreDestroy over the DatabaseManager where the selected local store gets opened in PostConstruct and gets closed in PreDestroy.  We registered each of the DAOs as beans and each has a PostConstruct where an aggregated non-bean private value uses the connection value in the DatabaseManager to create a collection of SQLStatement values which later get referenced by the DAO itself.  No real teardown or specific memory management happens with the non-bean type nor the DAOs themselves.

I thought the events may have stepped over each other too, but I don't feel certain any more since I can't isolate the cause.  I just know the SQLEvent.OPEN event never signals after the first time, which leads me to believe the beans themselves never set back up after tear down, which defeats the entire structure of integration testing with beans in this instance.

On Friday, 19 July 2013 13:48:19 UTC-4, Brian Kotek wrote:

[Brian Kotek]

I'm basically trying to reach back and remember, since I don't do any Flex development any longer and it's been several years. But if the beans are singletons and you tear them down, they may not get recreated since you're basically saying "I'm done with these". You might try to confirm that they're not being created again, and either try re-initializing the bean factory (or the whole Swiz instance) before each test, or try adding a method to the class that resets it and try calling that before each test. That way, instead of tearing it down, you keep the instance and just reset it back to a default state. 

[Brian J]

That makes a lot of sense.  Thank you, I'll try that.

Side question: which platforms do you develop for now?

[Brian Kotek]

For RIAs or mobile, Ext JS and Sencha Touch. For more simple interactivity on page-based web apps, just Bootstrap/jQuery/jQuery UI.

[Brian J]

Nice! We have an Ext team here, too.  Seems really different in a design context.

So far, no luck cloning or maintaining a reference to either the instance or the factory.  Same errors occur.

[Brian J]

I've tried cloning the BeanFactory and the Swiz instance, that didn't stop the application from throwing SQLConnection errors.
I tried a timer.  That did nothing either.
I tried waiting for the open event.  That did nothing.
I tried not extending AutowiredTestCase.  That did nothing.
I tried using the AutowiredTestCase example on the JIRA site.  That did nothing.
I tried using the application's bean provider MXML as the value for AutowiredTestCase's beanProviders mutator with public [Inject]ed attributes.  That did nothing.
This last approach still randomly throws the SQLConnection error, but it at least doesn't introduce any more problems and it doesn't require manual updating of the Swiz configuration for all tests extended from it.

On Monday, 22 July 2013 13:05:35 UTC-4, Brian Kotek wrote:

[Brian J]

I can't seem to attach a file here, so here's the base test case type in question:

/** Copyright 2013 Company.  All rights reserved. */
package testing.utilities {
    import com.project.configuration.Beans;
    import com.project.presentation.mappers.*;
    import com.project.presentation.mappers.template.*;
    import com.project.presentation.mappers.utilities.DatabaseManager;
    import com.project.presentation.services.*;

    import flash.events.EventDispatcher;

    import org.fluint.sequence.*;
    import org.swizframework.core.*;
    import org.swizframework.events.BeanEvent;
    import org.swizframework.utils.test.AutowiredTestCase;

    public class BeanTest
        extends AutowiredTestCase {
        [Dispatcher] public var dispatcher: EventDispatcher;
        [Inject] public var cMapper: CDAO;
        [Inject] public var dMapper: DDAO;
        [Inject] public var eMapper: UDAO;
        [Inject] public var iMapper: PDAO;
        [Inject] public var manager: DatabaseManager;
        [Inject] public var nMapper: NDAO;
        [Inject] public var rMapper: UDAO;
        [Inject] public var sMapper: SDAO;
        [Inject] public var uMapper: UDAO;

        [Inject] public var networkMonitorService: NetworkMonitorService;
        [Inject] public var iService: PService;
        [Inject] public var securityService: SecurityService;
        [Inject] public var remoteIObject: RemoteIObject;
        [Inject] public var securityObject: RemoteSecurityObject;

        [Before] override public function constructSwizContext(): void {
            swizConfig = new SwizConfig();
            swizConfig.eventPackages = 'com.project.presentation.events.*';
            beanProviders = [new Beans()];
            super.constructSwizContext();
        }

        [After] public function destroyBeans(): void {
            cMapper = null;
            dMapper = null;
            eMapper = null;
            iMapper = null;
            manager = null;
            nMapper = null;
            rMapper = null;
            sMapper = null;
            uMapper = null;
            networkMonitorService = null;
            securityService = null;
            iService = null;
            remoteIObject = null;
            securityObject = null;

        }
    }
}



On Monday, 22 July 2013 13:05:35 UTC-4, Brian Kotek wrote:

[Brian Kotek]

Not sure if it's your problem, but you're not tearing down the beans or the Swiz instance. Setting these values to null doesn't affect Swiz at all. I'd get rid of the null sets and try swiz.tearDown().

[Brian J]

Oh, okay, will do.  I'll let you know what happens!

[Brian J]

Damn, that seemed to make every test fail.  :(

On Monday, 22 July 2013 16:57:27 UTC-4, Brian Kotek wrote:

[Brian J]

More specifically, a new error raises and then every test fails.  The error reads:

TypeError: Error #1034: Type Coercion failed: cannot convert flash.events::SQLEvent@107a5511 to mx.rpc.events.ResultEvent.

On Monday, 22 July 2013 16:57:27 UTC-4, Brian Kotek wrote:

[Brian J]

Even more information: the following error also raises for most tests.

Error: InjectProcessor Error: bean of type [class X] not found!

Yet the provider I used works in the main application.

On Monday, 22 July 2013 16:57:27 UTC-4, Brian Kotek wrote: