I use TFS 2010 and I need using TFS API to retrieve an information about work items that were deleted. There is a table [WorkItemsDestroyed] in the TFS DB that contains the information about destroyed work items. Is there any way to get that information using TFS API?
It depends on what information you want to retrieve. If you want to find out who deleted the work item then you can do that with sql (#pantelif comment).
If you want to retrieve information about the work item itself I think there is not any way to do that, either from TFS API or sql command. As described at this post, you cannot recover deleted work items:
Deleting Work Item Action Is Not Recoverable
Actually, as long as the test plan has not been deleted, there should be full history of the actual test results allowing you to recover from the deletion of a test suite...it may take a bit of time, but process works.
Try this to re-create your test suites and associated results.
Recreate the suite.
Add tests if not a query-enable suite.
From Test tab, select your suite within the hierarchy.
Create some initial results to allow you to see full history for each test. Within the test lists pane, mass-select all test results and set them to blocked.
Now when you open each test result, you will see full list of previous test results history associated to each test case at the bottom of the results window.
In other words, you need to trigger an initial result to see the full history.
For any results only carrying a single “Blocked” result, the test has not been executed. (first time the result has been made)
For tests that have additional results associated to it, identify the last known state (see the Created date column), then set it appropriately (Pass/Fail/Blocked)
NOTE: This will only work as long as the Test Plan has not been deleted. If it is simply a test suite, this should get you back up and running quickly.
Related
I am using Azure DevOps WIT One Click Extension. I am trying to create a Rule to generate multiple Work Items (Child Tasks) when an specific Work Item gets saved or assigned to an individual.
I have tried over and over and the rule does appear for me to manually executed but it is not working to automatically generate the Tasks.
I have no code... I am not a Programmer or Developer. I am a user trying to use the tool
I expect the rule to work and automatically create the Child tasks when the Request Item (Parent) is saved or assigned to someone.
I'm afraid the trigger way you want does not support by this extension now.
generate multiple Work Items (Child Tasks) when an specific Work Item
gets saved or assigned to an individual
For this rule you would like -- save a specific work item and assigned to an individual are belong to trigger way -- as I understand, what you want is when a work item saved and be assigned to someone, it will trigger the action generate multiple child tasks.
So, in this rule, save a work item or assign it to someone is trigger way. The action is generate multiple child tasks. But, unfortunately, these trigger ways does not be support by this extension. It just support New work item load and Field changed now.
That's why it does not working automatically. Because the trigger way you configured not supported.
The rules you can create which also supported by this extension, is open a workitem or change one field will link a child task.
In addition, I also check the rules which Azure Devops support. The trigger way you want are also does not supported.
These users never had MTM installed locally but seems to have different default for test case shared steps query.
I'm not sure where to find these queries saved. or how to clear if it's cache related.
I know if there is MTM installation on user local machine, it will save user config settings mtm.AddSharedStepsGrid somewhere in systemDrive:\Users\{UserName}\AppData\Local\Microsoft\TeamTest\v*" but this is also occurring on user machines without MTM installation.
It has different default per user, cause the user have used/changed the query before.
TFS web portal will auto cached the last query option which user have selected.
You could test this in your side, just change some options, close the “insert shared steps” query, then open it again, it will changed.
Since there is not any button to save the "insert shared steps" query, you could only Run it. I think this is by designed as a temporary storage per user instead of the "save" option.
We now only have the first row i.e. Work Item Type in group Shared Steps. That wouldn't be different per user.
I understand cucumber and capybara are to mimic user actions to test web application. However, is it possible or recommended if I directly to fetch db record to have a test if some attributes are unable to find from web interface directly?
If yes, how to locate the db record created by current test case?
It's not recommended, but is possible, to do direct database access tests in feature tests. The main reason for this is that feature tests are intended to be black box tests that test a specific feature in the application from a users experience perspective (and users can't see into the DB, well shouldn't be able to anyway). In that case even though the value of some attribute of an object isn't technically visible in the UI the attribute has to have some effect on the record when shown (otherwise why have the attribute in the first place), and that effect should be testable via the UI.
In the rare cases where you do actually need to do direct database access you need to remember that you need to control synchronization between the UI and when you test the DB. For example the following test code would lead to at best flaky tests.
...
click_button('Do something')
expect(MyObject.last.some_attribute).to be true
...
This is because once the button has been clicked Capybara doesn't know about any further actions that click creates, and just returns. Then the DB access occurs before the request generated by the button click is processed and either there is no record yet, you're testing against the wrong record, or the state of the record hasn't been updated yet and the test fails. To fix this you need to insert an expectation between the click and the DB check to wait for the triggered action to finish
...
click_button('Do something')
expect(page).to have_content('Something has been done') # UI check that will succeed when the triggered action has completed
expect(MyObject.last.some_attribute).to be true
...
As for how to identify the DB record you want, you control all the test data, and it should be reset for every test. That way if you've just created a record it should be the last record (MyObject.last). If you're editing a record then you created the initial record in the setup for the test and should have access to it (my_test_object.reload...), etc...
Direct Links query can be created two ways in MTM
Plan->Contents->New Query-based suite->(query type)->Work Items and Direct Links
Track->Queries->New Direct-Link Query
First one creates a test suite in the end. Is there any other difference?
Your two techniques are doing different things and have different purposes.
Option 2 is simply doing a Work Item Query, the same way you can do in Team Explorer/Visual Studio and also Team Web Access.
Once you have viewed the information you can discard it or save it in "My Queries" or "Shared Queries". If you save it, you can view the results in Excel for example or perhaps share it with colleagues.
Option 1 is all about creating a Test Suite which is a grouping of Test Cases.
There are static suites which are essentially folders for grouping Test Cases.
There are requirements based suites - for example, add all the PBIs from Sprint 1 and then we can add Test Cases to ensure we have tested against their acceptance criteria.
Then there are query based suites which will add all the test cases which match your specified query. New test cases will be added if they match the query (eg. all high priority test cases)
Organizing Test Cases Using Test Suites(2012)
So, if you want a test plan then use option 1. If you want to simply run queries, use option 2 (or use team explorer/web access to do the same thing)
I am trying to write a TFS (2013) query to use as a check in rule (using the TFS Power Tools). I want to allow the user to check in against a requirement that is RESOLVED, and who's child tasks are all in the CLOSED state.
Using the "Work item and direct links" query type, I am able to return all the requirements that are eligible for association during check in. The problem is, the query will also return the child tasks, as below:
Requirement: This is my Requirement [Resolved]
Task : + This is the child task [Closed]
The idea is that in a branch people check their work in against the Tasks. When all the work is complete, and the tasks are closed, the branch can be merged. The requirement being moved to Resolved marks the work as complete, and ready for merge. It is the merge check in association that I want to validate with this query. The Team Lead verifies that the work has been completed to their satisfaction and performs the merge, checking in the code against the requirement.
How can I have my query return only the requirement work item, and not the task, whilst retaining the filtering?
Your scenario doesn't make sense to me, you only want to allow devs to check-in against Resolved Requirements's whose tasks are all closed? (that seems weird)
But you would create a query that returned all Requirements where State = Resolved and do the direct links but select the option "Only Return Items that do not have the specified links" and filter by all Tasks where State <> Closed.