Large app testing - getting started

[jumpwake]

Hello

We currently have an enterprise app utilizing .NET and ExtJS 4.06. I've spend the last few days messing around with Jasmine and Siesta, trying to get some unit tests setup to run through our ExtJS code (non MVC model). We have a lot of javascript wrapper classes around the Ext framework...i.e. setting up grids, stores, models, etc. I want to be able to mock our grid and then run unit tests against the rendered grid based on business rules previously defined.

Jasmine did not want to play nice with the dom so I started messing around with Siesta and I like the configuration, but I'm curious if I can leverage our suite of javascript classes for creating grids, models, etc. I need to leverage that code so we can test that a future change will not break our unit tests.

Any thoughts would be appreciated, I've somewhat hit a wall...

[mats]

Sounds like you're on the right path. We use our own Bryntum test class which contains all the wrapper/utility methods we need. You should do this:

Harness.configure({
    title     : 'Awesome Test Suite',
    
    testClass           : YourClass,

    preload : [
        // Jquery CDN
        'https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'
    ]
})

Include the file containing the YourClass class in the index.html file.

Class('YourClass', {

    isa: Siesta.Test.ExtJS,     // Extend the native Siesta.Text.ExtJS class

    
    methods: {
            getRenderedGrid : function() {
                  return new Ext.GridPanel({ ... });
}, ...
    

All these methods will be available on the test instance ('t' in the test bootstrap function). Does this help?

[jumpwake]

Thanks for the reply, I started looking into the sub-classing approach last night. Inside StartTest(t), am I only able to hit the methods in YourClass? For instace, we've got a method called CreateGrid which sets up a lot of the config, model, fields, etc.

Would I include our custom js files in the html page or as part of a preload? Once those are included, would I then take a few of the methods in our classes and put them into YourClass for specific testing?

i.e. Call our CreateGrid, then run a unit test using the Ext framework to double check that everything looks good? CreateGrid actually runs through a lot of code/classes to setup the grid.

If I can get the grid rendered via all of our method calls, I should be able to run some item searches and then do additional double checks with the Ext methods to also verify that grid properties are what we expected.

One last question....when our code gets to the point of hitting our ajax service (.NET ServiceManager - referencing c# web methods), will this actually execute or will it stop at this point? Jasmine has the spy that you can use to bypass CallAjax which is a little awkward when trying to test certain aspects.

Thanks again

[nickolay]

Include your custom js file in the preload (along with any css files if needed), index.html only sets up the harness UI, each test is run in separate iframe. No need to put the functionality of your application to the test class - put the repeating actions/custom assertions on it.

About ajax - currently the recommended approach is to mock your requests with static files - see /examples/024-extjs-crud for example. You can also use real server response, but you will need to make sure each test starts with the same state every time.

[jumpwake]

Success!

Incorporating our class files worked well. I just had to scope the variables above the StartTest so that the internal test class could see them. I also had to write a mockup of our AjaxClass file. Instead of calling the wcf service, I just mocked up what the response would look like and sent it to its Callback function. This worked really well having all of our methods run through this class.

I also had to incorporate the Ext.Loader and reference Ext.ux.data.PagingMemoryProxy since we are using that proxy. Is there a built-in Siesta function for requiring these extra classes?

Now that I've got the grid rendering via our enterprise classes, I should be able to write unit tests via Siesta and Ext to validate them from a different angle.

Thanks and I'm sure the deeper I get, the more questions I'll have.

[nickolay]

Great! Keep going and pretty soon you'll have much better confidence in your codebase.

I also had to incorporate the Ext.Loader and reference Ext.ux.data.PagingMemoryProxy since we are using that proxy. Is there a built-in Siesta function for requiring these extra classes?

Just include the Ext.ux.data.PagingMemoryProxy in your preloads.

[jumpwake]

Thanks for the reply.

What are the pros/cons to setting up multiple items/tests vs setting up 1 test with multiple assertions?

The overhead of setting up the classes and the grids seems like it might be a lot of overhead for our situation. Especially when I automate these tests in the future. Most of my tests will most likely be business assertions against the rendered grids.

Preface: The main page with all the functionality has a Toolbar, top grid, paging bar, and a second grid with paging.

[jumpwake]

Have you guys had any issues with getting the grid to render in Siesta? I know its there, I can run assertions against it. I'm rendering it to document.body. I can control it, just can't see it.

Any ideas?

[jumpwake]

Have you guys had any issues with getting the grid to render in Siesta? I know its there, I can run assertions against it. I'm rendering it to document.body. I can control it, just can't see it.

Any ideas?

Nevermind on this....I finally tracked down the issue. The examples are using RenderTo: document.body...and we have an invisible ErrorsGrid that was getting set to hidden....which in this case was setting the entire document.body to hidden. I ended up creating a new control on the fly for that ErrorsGrid and leaving the rest to document.body.

[mima1974]

Include your custom js file in the preload (along with any css files if needed), index.html only sets up the harness UI, each test is run in separate iframe. No need to put the functionality of your application to the test class - put the repeating actions/custom assertions on it.

About ajax - currently the recommended approach is to mock your requests with static files - see /examples/024-extjs-crud for example. You can also use real server response, but you will need to make sure each test starts with the same state every time.

Hello Nickolay!

I've make it wrong because i put some Test-functionality (e.g. Logon) to the test class. This I will change now.

I've created a "MyScript.js" file add it to the directory where the index.html and index.js also are. That file contains the following function:

function fTest(wert1) {
    alert(wert1)
}

My index.js look like that:

// Harness Ext 4
var Harness = Siesta.Harness.Browser.ExtJS

Harness.configure({
    title: 'Test-Case Logon',
    needDone: true,
    viewDOM: true,
    forceDOMVisible: $.browser.msie,
    autoCheckGlobals: false,
    testClass: Test.Base,
    waitForTimeout: 20000,
    consoledebug: false,
    settings: settings,
    runCore: 'sequential',
    preload: [
        'MyScript.js'
    ],
...
})

Now i was expected that I can use the 'fTest()' Function in my Test like that:

StartTest(function (t) {
     fTest('Hello')
  // or
    t.fTest('Hello')
})

but that don't go. I can only access that function via top.fTest('Hello').
The accessibility via top come from the index.html with the following line:
<script type="text/javascript" src="MyScript.js"></script>

Thx for your Help