Secondly, screenshots taken on error now highlight the component that was under test to make it easier to identify what the problem could be. We’ve also made two improvements to test result reports – first of all, they can now also be exported in JUnit report format to make it easier to integrate them into your continuous build and integration process. This works recursively as well, so you can clean up your unused Test Cases quickly and easily. The new feature “delete with orphans” lets you delete an unused Test Case (that you’ve found for example using the filter to show unused Test Cases) – and all of the Test Cases in it that will become unused once their parent is deleted. Getting rid of dead test code: delete with orphans This feature should save users a lot of clicking and scrolling. For users working with the function getCentralTestDataSetValue, it’s now possible to navigate between the properties view and the central test data sets view (and back again) to quickly see where a value is referenced, and which value is actually used in the function.This is really useful for navigating “back up” the hierarchy when you have multiple editors open. Double-clicking on a root node in the Test Case Editor jumps to the open editor where this Test Case is reused.Navigating in testsĪ while ago, we gathered some feedback from users and found that navigating in the ITE could be more comfortable in some places. In the test result report, you can see which steps have been skipped. This reduces the amount of duplication required to fill out fields in forms. The test step will simply not be executed. In Eclipse Oxygen, you can use the parameter value #jbskip# for any of the parameter values for a test step. Depending on the test case this is used in, it might only be relevant (or possible) to fill out the mandatory fields. fill out all the fields in a form / wizard page. Our test consultants at BREDEX use this pattern frequently – they create a keyword that will e.g. With Jubula’s focus on reusability, the question has often come up how keywords can be created that variably execute all or just some of the steps contained in them. The polling interval for the retries is configurable via a variable. If the check fails on the first try, it will be retried automatically until the timeout has expired. But now you can choose to set a timeout for any check action. The default is 0ms, so existing tests will still run. To make these actions more streamlined, we’ve added the parameter “TIMEOUT” to each check action. wait until a text has changed / a list item has appeared. Jubula does offer a great deal of “wait for” actions, but sometimes it’s necessary to e.g. One aspect that could previously make tests unnecessarily complicated was dynamic synchronisation. You can enter concrete values, parameters, references and functions. The repeat node allows you to enter an amount of times to repeat the do-block. The do-while loop works in the same way, but performs the action(s) in the do-block before the first check.Ĭonditions and loops are negatable (for those who can get their head around that!), and the true or false value of each condition is based on the outcome of the check actions within that block. “While there are tabs open, close the first tab” This was previously (and still is) possible using retry event handlers, but the conditions mean that it is easier to specify and to read. Some of the cool examples that you’ll be able to implement now are: “If a confirmation dialog is present, then click OK, otherwise do nothing” As always, with great power comes great responsibility ) We still see that danger, but we also see that there are some examples where having these constructs is going to make tests more readable, or certain more complex scenarios easier to automate. This is something that we’ve very explicitly not implemented in the past, because of the inherent danger of making tests over-complicated and unreadable. And that’s why we’ve introduced four new nodes: if-then-else, do-while, while-do and repeat. Nevertheless, some test scenarios require conditionality and loops. Otherwise, it’s hard to tell whether a green test is still green for the right reasons. I’m the first person to advocate for deterministic tests that run the same each time. We’ve also put some work into helping people who have larger test projects - we’ve improved the navigation in tests and have a new way of cleaning up dead test code. Which is why we think you’ll like Eclipse Jubula Oxygen edition: the new version lets you write more complex tests using conditions and loops, and lets you conditionally skip test steps. It’s always pleasing to be able to compile a “what’s new” overview that contains features that the community have been asking for.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |