Class('Your.Test.Class', {
isa : Siesta.Test.ExtJS,
methods: {
// ADD YOUR CUSTOM METHODS HERE
getGrid : function(config){
// Change to correct Ext scope
var Ext = this.global.Ext;
Ext.define('Gamer', {
extend : 'Ext.data.Model',
fields: [
{name: 'name'},
{name: 'highscore', type: 'int'},
{name: 'place', type: 'int'},
{name: 'lastgame', type: 'date', dateFormat: 'Y-m-d'}
]
});
var store = Ext.create('Ext.data.ArrayStore', {
model : 'Gamer',
data: [
['Mike', 10, 20, '2010-12-12'],
['Swedish Chef', 10, 20, '2010-01-12'],
['Jay', 10, 20, '2010-06-12'],
['Brian', 10, 20, '2010-04-12'],
['Geoff', 10, 20, '2010-08-12']
]
});
// create and return the grid
return Ext.create('Ext.grid.Panel', Ext.apply({
store: store,
columnLines : true,
columns: [
{
text : 'Name',
flex : 1,
sortable : false,
dataIndex: 'name',
field : {}
},
{
text : 'Highscore',
width : 75,
sortable : true,
dataIndex: 'highscore',
field : { xtype : 'numberfield' }
},
{
text : 'Rank',
width : 75,
sortable : true,
dataIndex: 'place'
},
{
text : 'Last game',
width : 85,
sortable : true,
renderer : Ext.util.Format.dateRenderer('Y/m/d'),
dataIndex: 'lastgame',
field : { xtype : 'datefield' }
}
],
height: 150,
width: 400,
title: 'Some Grid'
}, config));
}
}
});Support Forum
Your test class has to look like this:
Thank you, ok then I never was wrong in that case.
1)
The Test(Base)Class are to include by the "testClass' Harness config.
For waht is then the 'preload' functionality?
If I read the docs there stand: "The array which contains the preload descriptors describing which files/code should be preloaded into the scope of each test."
Why I cant access my Function via t.fTest() not?
2)
The next problem for me is that if I put all the CUSTOM-Reusebale methodes in the TestBaseClass then its going quickly to big.
I'm look for a solution like that schema:
Here in taht example I show that the base-class of 'Test.Base.Logon' is 'Test.Base'.
So the 'Helper-Fuctions' of 'Test-Base' can be used of the using classes.
With that concept I can expand it in future over different files where each file have the reuseable functions about one theme.
Other classes can be 'Test.Base.CampaignSelection', 'Test.Base.OpenCustomerBySearch'.
What you think about it?
Best regards
1)
The Test(Base)Class are to include by the "testClass' Harness config.
For waht is then the 'preload' functionality?
If I read the docs there stand: "The array which contains the preload descriptors describing which files/code should be preloaded into the scope of each test."
Why I cant access my Function via t.fTest() not?
2)
The next problem for me is that if I put all the CUSTOM-Reusebale methodes in the TestBaseClass then its going quickly to big.
I'm look for a solution like that schema:
Class('Test.Base', {
isa: Siesta.Test.ExtJS,
methods: {
// HELPER METHODES IN BASE FILE
getCmpByTestId: function (testId, scope) {
if (scope == undefined) {
console.log('Scope was undefined - use t.Ext()')
scope = this.Ext()
}
// Array von HTML elementen holen, die zur Abfrage passen
var arrayResult = scope.query("*[class*='test-id-" + testId + "']")
if (arrayResult.length != 0) {
// Ext-Component zum erst gefundenen HTML element zurückgeben.
return scope.getCmp(arrayResult[0].id)
}
else {
throw ("Value: " + "'test-id-" + testId + "' not found in any class property of DOM!")
}
}
})
Class('Test.Base.Logon', {
isa: Test.Base, // !!!!
methods: {
// METHODES FOR DIFFERENT LOGON TESTS
login: function (userName, password, workspace, callback) {
var username = t.getCmpByTestId('test-id-username-field') // use of t !!!!
.....
},
loginViaCase1: function (userName, password, workspace, callback) {
.....
},
})
So the 'Helper-Fuctions' of 'Test-Base' can be used of the using classes.
With that concept I can expand it in future over different files where each file have the reuseable functions about one theme.
Other classes can be 'Test.Base.CampaignSelection', 'Test.Base.OpenCustomerBySearch'.
What you think about it?
Best regards
@mima1973
Hi,
You can use Joose Roles for structuring your code:
One can say Test.Base consume Test.Base.Logon - all the methods defined in it, will be added to consuming class. For concrete rules about how it works see https://joose.github.com/Joose/doc/html/ ... Roles.html
See also examples in Siesta sources.
Hi,
You can use Joose Roles for structuring your code:
Role('Test.Base.Logon', {
// no "isa" !
methods: {
// METHODES FOR DIFFERENT LOGON TESTS
login: function (userName, password, workspace, callback) {
var username = t.getCmpByTestId('test-id-username-field') // use of t !!!!
.....
},
}
})
Class('Test.Base', {
isa : Siesta.Test.ExtJS,
does : Test.Base.Logon,
methods: {
// HELPER METHODES IN BASE FILE
getCmpByTestId: function (testId, scope) {
}
}
})
See also examples in Siesta sources.
Read the API documentation
Wow tahts very cool.
Thats running fine. I get now only that exception that in 'Test.Base.Logon' is 't' not defined (In that case I need the helper functions from 'Test.Base' eg. getCmpByTestId() etc..) .
My current Idea is to make a Role 'Test.Base.Helpers' where
'Test.Base' and 'Test.Base.Logon'
does : Test.Base.Helpers
Can I set an array (many values) as 'does' value(s)?
Did you have a better idea?
Thats running fine. I get now only that exception that in 'Test.Base.Logon' is 't' not defined (In that case I need the helper functions from 'Test.Base' eg. getCmpByTestId() etc..) .
My current Idea is to make a Role 'Test.Base.Helpers' where
'Test.Base' and 'Test.Base.Logon'
does : Test.Base.Helpers
Can I set an array (many values) as 'does' value(s)?
Did you have a better idea?
Sure, "does" accept several roles in array. Though if Test.Base.Logon will "does" Helpers and Test.Base will "does" Test.Base.Logon, then there's no need to "does" Helpers in Test.Base
Read the API documentation
Use "this" instead of "t" from inside of testing class methods (t is the instance of test class)mima1974 wrote:Wow tahts very cool.
Thats running fine. I get now only that exception that in 'Test.Base.Logon' is 't' not defined (In that case I need the helper functions from 'Test.Base' eg. getCmpByTestId() etc..) .
Read the API documentation