[*] Add more examples
[*] Improve the testing of asynchronous code - make tests easier to read / write.
[*] Automate launching of the test suite in several browsers simultaneously
[*] Improve the user interface.
[*] Add more / improve documentation
[*] Create a special harness targeting mobile devices
[*] Simulate all the keyboard events across all browsers
[*] Add a special "presentation mode" with a lot of visual accompaniment for tests execution.
[*] Add benchmarking support.
[*] Add ExtJS MVC assertions pack
Support Forum
Below is the list of features in our roadmap - please review and let us know what's important to you! Please PM me the re-ordered list from thread, starting from most important features for you.
Read the API documentation
We are a Siesta Standard + Premium Support subscriber.
[1] Sencha Touch 2 support (see this in 1.1.0-preview, nice =) )
[2] Touch event simulation (not in 1.1.0-preview)
[3] Create a special harness targeting mobile devices
[4] Add DeftJS (https://deftjs.org/) MVC assertions pack
Note: ExtJS 4.1 MVC != ST2 MVC and both are vastly inferior to DeftJS MVC which also supports both frameworks.
[5] Improve the testing of asynchronous code - make tests easier to read / write.
[6] Add a special "presentation mode" with a lot of visual accompaniment for tests execution.
[7] Add benchmarking support. (currently we use benchmark.js https://benchmarkjs.com/)
[8] Add more examples
[9] Automate launching of the test suite in several browsers simultaneously
[10] Improve the user interface.
[11] Add more / improve documentation
[12] Simulate all the keyboard events across all browsers
https://smxcloud.com Clouds, not smoke.
Thanks for feedback 
Some comments:
[2] Touch event simulation (not in 1.1.0-preview)
You have tap, longpress, swipe, doubleTap. What else do you require?
[3] Create a special harness targeting mobile devices
Already in 1.1 (examples-touch)
[4] Add DeftJS (https://deftjs.org/) MVC assertions pack
Good idea
Note: ExtJS 4.1 MVC != ST2 MVC and both are vastly inferior to DeftJS MVC which also supports both frameworks.
[5] Improve the testing of asynchronous code - make tests easier to read / write.
Have you tried using t.chain? Keeps our async tests clean!
[6] Add a special "presentation mode" with a lot of visual accompaniment for tests execution.
Like a 'Run test in fullscreen mode'?
[7] Add benchmarking support. (currently we use benchmark.js https://benchmarkjs.com/)
Already on Todo, though likely not soon.
[8] Add more examples
Would be nice! Please note you can also check the 'tests' folder for how Siesta itself is tested. Contains a big bunch of additional tests.
[9] Automate launching of the test suite in several browsers simultaneously
This requires a cloud service of some sort, already on todo-list but will take some time.
[10] Improve the user interface.
Quite vague. Wishlist?
[11] Add more / improve documentation
Anything in particular, guides?
[12] Simulate all the keyboard events across all browsers
Not easy, could be done if we switch to native events via Java Applet. Also on todo list (it's quite long)
Some comments:[2] Touch event simulation (not in 1.1.0-preview)
You have tap, longpress, swipe, doubleTap. What else do you require?
[3] Create a special harness targeting mobile devices
Already in 1.1 (examples-touch)
[4] Add DeftJS (https://deftjs.org/) MVC assertions pack
Good idea
Note: ExtJS 4.1 MVC != ST2 MVC and both are vastly inferior to DeftJS MVC which also supports both frameworks.
[5] Improve the testing of asynchronous code - make tests easier to read / write.
Have you tried using t.chain? Keeps our async tests clean!
[6] Add a special "presentation mode" with a lot of visual accompaniment for tests execution.
Like a 'Run test in fullscreen mode'?
[7] Add benchmarking support. (currently we use benchmark.js https://benchmarkjs.com/)
Already on Todo, though likely not soon.
[8] Add more examples
Would be nice! Please note you can also check the 'tests' folder for how Siesta itself is tested. Contains a big bunch of additional tests.
[9] Automate launching of the test suite in several browsers simultaneously
This requires a cloud service of some sort, already on todo-list but will take some time.
[10] Improve the user interface.
Quite vague
. Wishlist?[11] Add more / improve documentation
Anything in particular, guides?
[12] Simulate all the keyboard events across all browsers
Not easy, could be done if we switch to native events via Java Applet. Also on todo list (it's quite long
)
Hello,
if this is the right place for feature request, here is a suggestion:
- allow regexp (or at list wildcard) in expectedGlobals.
- rationale: jQuery1.7.1 (at least) creates not only the global jQuery, but also unpredictable globals such as jQuery17109183830059506592. This makes Siesta complain at global check. So it would be nice to be able tell Siesta ignore all 'jQuery*'.
This is probably not the top 1 feature, but I assume it is fairly easy to implement, so it can be a quick win.
if this is the right place for feature request, here is a suggestion:
- allow regexp (or at list wildcard) in expectedGlobals.
- rationale: jQuery1.7.1 (at least) creates not only the global jQuery, but also unpredictable globals such as jQuery17109183830059506592. This makes Siesta complain at global check. So it would be nice to be able tell Siesta ignore all 'jQuery*'.
This is probably not the top 1 feature, but I assume it is fairly easy to implement, so it can be a quick win.
Make sense, will be implemented in next release.gabrielle wrote:Hello,
if this is the right place for feature request, here is a suggestion:
- allow regexp (or at list wildcard) in expectedGlobals.
- rationale: jQuery1.7.1 (at least) creates not only the global jQuery, but also unpredictable globals such as jQuery17109183830059506592. This makes Siesta complain at global check. So it would be nice to be able tell Siesta ignore all 'jQuery*'.
This is probably not the top 1 feature, but I assume it is fairly easy to implement, so it can be a quick win.
Read the API documentation
Would be nice if for example the firesOk, firesOnce and equal methods could print their output at the location were you called them.[5] Improve the testing of asynchronous code - make tests easier to read / write.
When I have something like: t.diag('events'); t.fireOnce(observable, 'event', 'event fired'), fire(); t.diag('next test');
The result of the fireOnce assertion ('event fired') will be printed bellow 'next test' instead of 'events'.
Could you insert something like a placeholder in the result list at the position were t.fireOnce is called and then put the output of the assertion there? You could create an empty row with a uniqe id and then just update this row with the assertion result.
This would improve the clearness and readability very much!
I see that it is easy to manipulate HTML with JS and refresh a table row, but its hard to accomplish something like this with the phantomJS output.
But more important than the output is (propalby) for most people the JUnit report, and there you dont need to change a thing, because only the failed assertions are printed and t.diag is left out completely.
Most of the time (I imagine) people use the small/standard output of the phantomJS test were no t.diags are printed and only the failed assertion inside a test are printed, so no problem there after all!
But for Browser-Testing I always use the UI and get all confused because my event assertions are printed at the very end of the list.
Hm.. We'll think about this improvement. As you mentioned it won't work for automation, but can be implemented for graphical UI.
Read the API documentation
The chaining API is confusing to me. I think if there were a list of available method's you can chain, that'd be great. Also, there really aren't very many examples of mixing chaining classes. Take the Actions.wait api docs - I would never really call a wait w/o executing other code afterwards... its a bit confusing how this might work in practice.
@Derek.Adair - Please take a look at https://bryntum.com/products/siesta/docs ... thod-chain
A step in the chain is always a function or a config object for an action (its not a method). To find a list of available actions see classes in documentation in the Siesta.Test.Action.* namespace
A step in the chain is always a function or a config object for an action (its not a method). To find a list of available actions see classes in documentation in the Siesta.Test.Action.* namespace
Read the API documentation