In Quality Center, I want to move a test run with Passed/Failed status from one test set to another, copying its run history as well.
Please help, how can i do that.
You cannot copy single test case from one test set to another , though you can copy the entire test set and paste it and then delete the unwanted test cases. That seems to be the best possible solution as far as i know.
The ALM Client will not let you move a test run from one test instance to another, nor a test instance to another test set.
You would need to copy the details of the run into the new set either manually, or basically do the same thing through the OTAClient API.
It is highly recommended not to update the database directly. However, we had the same issue and ONLY IF YOU KNOW THE DATA MODEL AND KNOW EXACTLY what you are doing, you can change the ID of the TC_TESTCYCL_ID in the RUN table to the new one to move it. It has been a while since I did this so you need to check the other tables and make sure this is the only ID that you need to change. If you really want to do this I can look into it further.
Related
I'm building a Iceberg tables on the top of a data lake. These tables are used for reporting tools. I'm trying to figure out what is the best way to control a version/deploy changes to these tables in CI/CD process. E.g. I could like to add a column to the Iceberg table. To do that I have to write a ALTER TABLE statement, save it to the git repository and deploy via CI/CD pipeline. Tables are accessible via AWS Glue Catalog.
I couldn't find to much info about this in google so if anyone could share some knowledge, it would be much appreciated.
Cheers.
Version control of Iceberg tables.
Agree with #Fokko Driesprong. This is a supplement only.
Sometimes, table changes are considered as part of task version changes. That is, table change statements, ALTER TABLE, are bound to task upgrades.
Tasks are sometimes automatically deployed. So it often executes a table change statement first, and then deploys a new task. If the change is disruptive, then we need to stop the old task first and then deploy the new one.
Corresponding to the upgrade, we also have a rollback script, of course, the corresponding table change statement.
thanks for asking this question. I don't think there is a definitive way of doing this. In practice I see most people bundling this as part of the job that writing to the Iceberg table. This way you can make sure that new columns are populated right away with the new version of the job. If you don't do any breaking changes (such as deletion of column), then the downstream jobs won't break. Hope this helps!
I am currently writing a text with R bookdown and asked two friends to read my text and give comments, corrections and general feedback. My source files for the text are stored on GitHub and I would like my collaborators to make changes in the files (one for each chapter) with the help of git. However, none of us are really experts on git. This makes it hard to figure out what a suitable workflow is.
For now, we decided that each one of them creates himself a branch so that he does not directly push into the master branch. After I have read their changes I would like to decide what I merge into the master branch and what not. So far, it looks like each change needs to be in a separate commit because I am not able to merge single lines from a specific commit (not sure if that is at all possible). However, this seems like a lot of annoying and unnecessary commits to create. So, I guess I am looking for a way to avoid that and/or general pointers towards a good workflow for such kind of projects.
A useful command will be git cherry-pick, it allows you to select specific commits from a branch.
A general good practice is that commits should be self contained (if applied alone they make sense) and they target a specific feature (in the use case mentioned, that could be a paragraph or a section or a chapter).
In the end, if you would like to apply only specific changes of a commit, that would have to happen manually, someone has to decide which parts to apply and which not. A commit can be edited using git rebase -i <branch name> before being merged. This question might also be useful.
I finally found what worked for me in here. Basically, on my master branch I had to use
git merge --no-commit --no-ff branch-to-merge
This will merge all changes into my master branch but does not immediatly commit the changes so that they can still be staged/unstaged. Then, I can decide what line change to include by staging the line changes I want to keep and discard all other line changes. Finally, I commit all staged line changes et voilà, that's what I wanted to get.
Sidenote: I am using gitkraken and as a beginner with git I enjoy using the GUI but the merge part with the options "no-commit" and "no-fast-forwarding" had to be done via the git console (at least I could not find a way to to that using the GUI). Choosing which lines to stage and which to discard is then an easy task via the GUI.
I have a set of R functions which get called from a Ruby application and would like to test them. The R functions access data from a Postgres database so to write tests I need to populate a test database with some sample data.
I would like to avoid cleaning up the database within every test case. It would be nice if I could start a transaction before every test and rollback the transaction after.
The last paragraph of the "Writing Tests" section of this page http://r-pkgs.had.co.nz/tests.html makes me think that it's not possible to execute a block of code before every test case.
Does anyone know of any creative work arounds? I'm considering forking the project and adding the functionality but wanted to make sure I'm not reinventing the wheel.
For anyone who stumbles upon this, I ended up creating a wrapper function for test_that() which I use when getting data from postgres. Below is my solution:
db.test_that <- function(description, test_code) {
dbGetQuery(database_connection, 'BEGIN TRANSACTION')
test_that(description, test_code)
dbRollback(database_connection)
}
I'm writing some functional tests for an API in Symfony that depend on having data in the database. It seems the generally accepted method for doing this is to use Fixtures and load the fixtures before testing.
It seems pretty daunting and impractical to create a robust library of Fixture classes that are suitable for all my tests. I am using the LiipFunctionalTestBundle so I only load the Fixtures I need, but it only makes things slightly easier.
For instance, for some tests I may need 1 user to exist in the database, and other tests I may need 3. Beyond that, I may need each of those users to have slightly different properties, but it all depends on the test.
I'd really like to just create the data I need for each test on-demand as I need it. I don't want to pollute the database with any data I don't need which may be a side effect of using Fixtures.
My solution is to use the container to get access to Doctrine and set up my objects in each test before running assertions.
Is this a terrible decision for any reason which I cannot foresee? This seems like a pretty big problem and is making writing tests a pain.
Another possibility it to try and use this port of Factory Girl for PHP, but it doesn't seem to have a large following, even though Factory Girl is used so widely in the Ruby community to solve this same problem.
The biggest reason to fixture test data in a single place (rather than in each test as needed) is that it allows you to isolate test failures from BC-breaking schema changes to only tests that are affected by the changes directly.
A simple example:
Suppose you have a User class, in which you have a required field name, for which you provide getName() and setName(). You write your functional tests without fixtures (each test creating Users as needed) and all is well.
Sometime down the road, you decide you actually need firstname and lastname fields instead of just name. Naturally you change the schema and replace getName/setName with new get and set methods for these, and go ahead and run your tests. Test fail all over the place (anything that sets up a User), since even tests that don't use the name field have called setName() during the setup, and now they need to be changed.
Compare to using a fixture, where the User classes needed for testing are all created in one fixture. After making your breaking change, you update the fixture (in one place / class) to setup the Users properly, and run your tests again. Now the only failures you get should be directly related to the change (ie tests that use getName() for something, and every other test that doesn't care about the name field proceeds as normal.
For this reason it's highly preferred to use fixtures for complicated functional tests where possible, but if your particular schema / testing needs make it really inconvenient you can set entities up manually in tests, but I'd do my best to avoid doing so except where you really need to.
I am facing a common issue that most of us face while writing UI automation tests:
Strong coupling of automation tests with the AUT. If an enhancement changes UI of a module, you have to go and spend a lot of time changing:
1. Either the code (logic) to test the module.
2. Or just the locator of an element.
If the change in UI is minimum, it's ok to manually replace the locators in the test. But it is not possible to do this if the change is very large considering deadlines and time constraints.
I am trying to figure out a way to implement a tool / utility that will save my time from changing locators of any element in the web-app that I have stored in my locator map.
For example:
I have a locator for a search result list in my locator-map as:
searchResultsLocator=span[id="searchResults"] > ul > li[class="ui-menu-item"] > a
If a dev changes this by replacing the span with a div as a part of some patch, then I want this to get automatically get updated in my locator-map.
Has anybody worked on this problem? Can someone suggest something?
I am not sure if the problem is fixed or not, if not fixed you can try this..
I face the same issue is well but no more.
Create a file where you keep all the element references (if no ID is present you can use XPath) and then use a variable which takes value from this file instead of hardcoding it.
Do not create a single file for entire application, make sure you have related elements in a single file (say element of single page).
So when the UI changes you will have only one place to edit instead of entire test code.
You can use multiple/backup locators for each element. See my question here: Pros/cons for using multiple locators per element in Selenium?
This doesn't automatically update your locators for you, but I was afraid attempting to do so might update them incorrectly. And then you might end up with a kind of false positives - tests which pass because they auto-updated to new locators, but locators for the wrong elements!
However, pre-defining multiple locators allows your test to continue running smoothly when one locator fails, but you can generate reporting/notification about the failure, and then still have time to do your manual updating of locators, as long as at least one of those backups continues working.