Skip to main content
Participant
June 5, 2009
Answered

Expected/Actual values in test runner

  • June 5, 2009
  • 1 reply
  • 1399 views

Hey,

I've added public test functions to my classes like:

     [Test]
     public function basicTest():void
     {
         Assert.assertEquals("Test is 5 == 5", 5, 5);
     }

and a test suite takes this class as a variable.

[Suite]
    [RunWith("org.flexunit.runners.Suite")]   
    public class ModulesTestSuite {
        public var t1:MyClass;
    }

I use this mxml to run the tests:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="runMe()" xmlns:flexUnitUIRunner="http://www.adobe.com/2009/flexUnitUIRunner"
    styleName="flexUnitApplication" >
   
    <mx:Script>
        <![CDATA[
            import org.flexunit.runner.notification.async.XMLListener;
            import org.flexunit.listeners.UIListener;
            import org.flexunit.runner.Request;
            import org.flexunit.runner.FlexUnitCore;


            private var core:FlexUnitCore;

            public function runMe():void {

                core = new FlexUnitCore();

                core.addListener( new UIListener( uiListener ));
               
                core.run(ModulesTestSuite);

          ......

But, when the test runner runs the tests, it categorized them as empty tests and shows blank for expected and actual values. Whereas clearly i've entered '5' for both. The tests complete successfully though.

Could you please elaborate on what are empty tests and how to pass expected value/ actual value data that will display in the test runner UI.

Thanks,

Prannay

This topic has been closed for replies.
Correct answer mlabriola

This is mostly UI confusion right now. We are using the FlexUnit1 test runner during the alpha and beta and have not yet customized it well for our needs.

FlexUnit1 did assertion counting, meaning it knew how many times you made assertions in each method. Right now FlexUnit 4 does not do this, so it believes this test is empty because it doesn't know that you made an assertion.

This will be fixed in the next release bits, but for now, just look at failed tests or tests that succeeded and try to ignore the empty ones.

If you change your test to assert that 5 is equal to 6 ( and all is working right) I am guessing you will see a failure, which is just a way to prove all is running fine.

Mike

1 reply

mlabriolaCorrect answer
Participating Frequently
June 5, 2009

This is mostly UI confusion right now. We are using the FlexUnit1 test runner during the alpha and beta and have not yet customized it well for our needs.

FlexUnit1 did assertion counting, meaning it knew how many times you made assertions in each method. Right now FlexUnit 4 does not do this, so it believes this test is empty because it doesn't know that you made an assertion.

This will be fixed in the next release bits, but for now, just look at failed tests or tests that succeeded and try to ignore the empty ones.

If you change your test to assert that 5 is equal to 6 ( and all is working right) I am guessing you will see a failure, which is just a way to prove all is running fine.

Mike

PrannaybAuthor
Participant
June 5, 2009

Yup. Upon failure it shows up as failed with the expected and actual values displayed in the test runner UI.

It works for the purpose nicely, with the informative failures, but I hope you guys integrate and upgrade soon so that successful tests also have that info so that testers don't have to dig into the code to figure out what the tests are.

Keep up the good work!

-Prannay

Participating Frequently
June 5, 2009

Honestly, I am not sure when all passing tests will have this info. In particular FlexUnit4 makes use of hamcrest, and those assertions can be quite complicated. It is easy to describe a failure, some value did not conform in some meaningful way, but we don't have a good handle yet on how that will work for every success.

Keep your eyes on the builds though. There are some other great things coming that will help your cause.

Mike