Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004196TestLinkTest Executepublic2011-01-26 13:502013-08-06 13:13
ReporterJulian 
Assigned Tofman 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.9.1 (bug fixing) 
Fixed in Version1.9.3 (2011 Q3 - bug fixing) 
Summary0004196: Usability: Tree is collapsed after execution
DescriptionUsability: Tree is collapsed after execution
Steps To ReproduceHere are some hints - not so easy to reproduce - maybe enough:
1. Create 2 Test suites with 3 sub test suites
2. Create a test case on lowest test suite level for all top level suites
3. open execution
4. Expand Testuite 1 to lowest level
5. execute test case on lowest level (save result)
4. Expand Testuite 2 to lowest level (leavel test suite 1 expanded!)
5. execute test case on lowest level (save result)
-> test suite 2 is collapsed - test suite 1 is still expanded
TagsNo tags attached.
Database (MySQL,Postgres,etc)-
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Filesxml file icon testsuites4issue4196.xml [^] (1,843 bytes) 2011-06-12 19:59

- Relationships
has duplicate 0004604closedJulian Bad management of tree update. 

-  Notes
(0013448)
Julian (reporter)
2011-01-27 10:41

seems like only 1 branch of the tree can be expanded.

Example:

a%3As%253A/109/4524/4558%5Es%253A/109/4528/4570/143

a%3As%253A/109/4528/4570/143%5Es%253A/109/4524/4558

Both cookie values should restore the same state of the tree, but only ther first branch is evaluated:

Lets try to split the cookie values logically:

a%3As = some sort of prefix
%253A = indicates new "branch"
%5Es = seperates two "branches"
/109/4528/4570/143 = nodes of the branch (for test spec view means ids of test suites to expand)

everything after %5Es seems to be ignored
(0013449)
Julian (reporter)
2011-01-27 10:42
edited on: 2011-01-27 10:43

problem seems not to exist on test spec tree but on test exec tree.

issue is easy to reproduce by expanding some test suites and clicking the "Update tree after every operation" checkbox or the reset filters button

(0013450)
Julian (reporter)
2011-01-27 10:45

cookie name is not set properly for exec tree:
test spec tree: ys-tproject_109_ext-comp-1001
exec tree: ys-undefinedext-comp-1001
(0015239)
difool (reporter)
2011-06-12 07:20

If i plan to work on that, does the cookie idea is the correct one ?
(0015242)
Julian (reporter)
2011-06-12 08:07

I just collected some ideas and observations. Might be the wrong approach.
But if it is really not reproducable on test spec tree you could start to compare cookies or/and compare how the tree is initalized.
(0015249)
fman (administrator)
2011-06-12 20:00

attached XML file to create structure described on Steps to reproduce
(0015250)
fman (administrator)
2011-06-12 20:10

Difference between two trees are construction:


  • test spec tree (till filters are applied) is build in LAZY mode, i.e. just traversed on USER action.

  • test exec tree is build in STATIC way, i.e all tree is traversed to create it.
(0015255)
Julian (reporter)
2011-06-14 09:07

Possible solution to check found by francisco:

execTreeWithMenu.js:

// var path = this.state[i]; // error
var path = stateToRestore[i]; // seems tofix

Will try to check solution. same code also exists for other trees. simply search project for "stateToRestore"
(0015256)
Julian (reporter)
2011-06-14 10:41
edited on: 2011-06-14 10:42

execTreeWithMenu.js:
add "alert(newState);" on TreePanelState.prototype.saveState = function(newState)


Create Test Suites this way and add to test plan after:
project root
. suite_level_1
.. suite_level_2
... suite_level_3
.... test_case_level_3

Open Test Execution:
1. Expand root node
-> newState = /project_id
2. Expand suite_level_1
-> newState= /project_id/suite_level_1_id
3. Expand suite_level_2
-> newState= /project_id/suite_level_1_id/suite_level_2_id
4. Expand suite_level_3
-> newState= /project_id/suite_level_1_id/suite_level_2_id/suite_level_3_id
-> Now test case is visible
5. Collapse suite_level_1
-> newState= /project_id
6. Expand suite_level_1
-> newState= /project_id/suite_level_1_id
BUT test case is visible again -> correct state should be: /project_id/suite_level_1_id/suite_level_2_id/suite_level_3_id

(0015257)
Julian (reporter)
2011-06-14 11:17
edited on: 2011-06-14 11:44

The reason why the solution by francisco works is:

1. tree state is copied to new variable: var stateToRestore=this.state;
2. when tree is expanded according to the state within the loop the variable this.state is changed (see TreePanelState.prototype.onExpand = function(node) )
-> if stateToRestore is used (copy of this.state) the initial values are preserved.

I will apply the fix to all trees:
execTree.js
execTreeWithMenu.js
tcTree.js
treebyloader.js


Problem described in last post is another problem and will be handled in another issue -> 0004615

(0015258)
Julian (reporter)
2011-06-14 11:34

Branch 1.9:
http://gitorious.org/testlink-ga/testlink-code/commit/ca13cbd4781788940ac3652157715e8edad49e47 [^]

Master:
http://gitorious.org/testlink-ga/testlink-code/commit/42a51e0e1d366b9d9c9a157254d76c36ea1885c7 [^]
(0015431)
fman (administrator)
2011-07-02 13:49

1.9.3 released

- Issue History
Date Modified Username Field Change
2011-01-26 13:50 Julian New Issue
2011-01-26 13:50 Julian Status new => assigned
2011-01-26 13:50 Julian Assigned To => asimon
2011-01-27 10:41 Julian Note Added: 0013448
2011-01-27 10:42 Julian Note Added: 0013449
2011-01-27 10:43 Julian Note Edited: 0013449 View Revisions
2011-01-27 10:45 Julian Note Added: 0013450
2011-01-27 10:45 Julian View Status public => private
2011-06-11 09:40 Julian Relationship added has duplicate 0004604
2011-06-11 10:17 Julian View Status private => public
2011-06-12 07:20 difool Note Added: 0015239
2011-06-12 08:07 Julian Note Added: 0015242
2011-06-12 19:59 fman File Added: testsuites4issue4196.xml
2011-06-12 20:00 fman Note Added: 0015249
2011-06-12 20:10 fman Note Added: 0015250
2011-06-14 09:07 Julian Note Added: 0015255
2011-06-14 10:41 Julian Note Added: 0015256
2011-06-14 10:42 Julian Note Edited: 0015256 View Revisions
2011-06-14 11:17 Julian Note Added: 0015257
2011-06-14 11:19 Julian Note Edited: 0015257 View Revisions
2011-06-14 11:34 Julian Note Added: 0015258
2011-06-14 11:34 Julian Status assigned => resolved
2011-06-14 11:34 Julian Fixed in Version => 1.9.3 (2011 Q3 - bug fixing)
2011-06-14 11:34 Julian Resolution open => fixed
2011-06-14 11:34 Julian Assigned To asimon => fman
2011-06-14 11:44 Julian Note Edited: 0015257 View Revisions
2011-07-02 13:49 fman Note Added: 0015431
2011-07-02 13:49 fman Status resolved => closed



Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker