I'm currently using Team Foundation Server 2008 as a source control and build engine.
When I checkin some changes and associate the change with a work item the work item flow I've defined changed the status from active to ready for test. Unfortunately this is not accurate as it's not actually ready for test until a build is completed. Is there any way to make it so that a build can change the status of work items?
I don't think there is a custom task in MSBuild that allows you to update a work item. You could easily write one though. See this article:
http://msdn.microsoft.com/en-us/library/bb130320%28VS.80%29.aspx
This one show you how to write a task
http://msdn.microsoft.com/en-us/library/t9883dzc.aspx
Related
As the title of this post says I want to test a BizTalk-Orchestration. In past I did something like that by using BizUnit. But I was only able to test the Input, let the BizTalk-solution run and test the output. BizUnit helped me by automatizing this process.
So the question is:
How can I test every step in an Orchestration (for example the output of Transform component). How can I read the messages in the MessageBox while I'm testing that?
Does anyone know a great tutorial?
I agree with Johns-305 and would suggest that its not probably required to test every step of the Orchestration.
Still if you want to, you could put temporary Send shapes after every transformation and send them out to a FILE location so that you can understand what messages are being generated.
Also, you can make use of Orchestration Debugger if you want to understand the flow of the Orchestration.
You wont be able to see any messages that are created within the orchestration but are to published to the message box.
You can debug the orchestration in the BizTalk administrator console.
Just stop your orchestration. then in the BizTalk group you can attach debugger.
Then you can resume in debug mode
The first question you need to ask yourself is: Do I really need to do this? Hint, the answer is no.
The Unit Test fad has long past and was never a useful thing with BizTalk apps.
Instead, focus on developing, with the business owners, a set of test cases that validate the entire app. You then use these to test everything, not just Orchestrations.
During DEV, 97% of the time, testing in Visual Studio is all you need for Maps.
Is there a way to mark a test as XFAIL in robot framework?
I would like to execute the tests and if they have a defect tag associated with them I would like to mark them as XFAIL.
Is it possible to implement this using ResultWriter or any other module.
I found this as a workaround that seems to be acceptable: Add this to your test case:
# REMOVE WHEN FIXED!
Pass execution
... This test fails and is a known bug! (add bug ref here)
... Known Bugs
This way known bugs are forced to pass but are tagged as "Known Bugs" and are visible in the run log.
If having support for multiple test case statuses is important, have a look at the Robot Framework plugin for generating XML files that are compatible with the Allure reports. Have a look here for an example report.
In the Allure reporting there are 5 statuses (Failed, Broken, Cancelled, Pending and Passed) in addition to 5 severity statuses (Blocker, Critical, Normal, Minor & Trivial). As Robot doesn't support these statuses a lookup is done on the set tags and based on those it determines the Allure Status and Severity.
In case Allure Report plugin doesn't work for you, perhaps you can use it's approach to generate a log file of your own through Robot Listener functionality. This is a set of predefined events that you can create a class for. Log Message and Message being two of particular interest to you.
The other one is a recently released project Robot Background logger that extends the standard logger class of Robotframework. This should provide some control over the formatting of the message.
I have set up a Multivariate test in Sitecore 8.1. In Experience Editor i have a notification,it says item has a active test and Optimization tab shows red button but status shows no tests. I did check in the analytic database no test record found. I did deploy the Test from Workflow and its running. I am getting all options to stop, cancel and suspend. Sitecore is not testing my variations can any one help me to resolve this?
From what you are describing it sounds like the Sitecore_testing_index is erroneous. Perhaps the index is invalid, not built or not present. This index is required for Sitecore's Experience Optimisation to find the Tests in their various states.
I recommend getting a default copy of Sitecore.ContentTesting.Solr.IndexConfiguration.config from a fresh install and copy it to the path App_Config/Include/ContentTesting.
Once that is done, rebuild the Index via the Index Manager. You should then be able to find tests in the Experience Optimisation.
If you're still having trouble I recommend replacing the entire contents of App_Config/Include/ContentTesting with the files from a fresh install. And re-indexing.
I also recommend having a look against the Item which has the Multivariate test it should be within the default field Page Level Test Set. It should have values something along the lines of this
If it is populated but you are still unable to the Test, follow this guide how to create Multivariate Tests in Sitecore to identify where something is going wrong.
We are using TFS 2010 and we've got a requirement to run a separate EXE to execute our old VB6 build script. We've got 3 build agents spread across 2 machines but only one machine has the VB6 development environment on it (as well as the old build script) so only one agent can do this work. I know how to do this with a build activity in our build template file but because we've got 3 build agents on 2 different machines, my question is how can I make sure this activity only runs on the one build agent which contains the VB6 development environment?
I realize this creates a bottleneck but it's only temporary for now. It would be ideal if I could do this without creating a custom DLL for a custom activity. Also, I understand with tagging I could create a different build definition for this work but again, this is not ideal... I want one build workflow that runs this on the one agent but the rest of the activities afterward continue on their respective build agent(s).
EDIT: All that said above, if it is possible to chain 2 build definitions together (the VB6 build definition runs and then the "regular" build definition), that would be an acceptable solution if possible.
You could certainly chain together 2 build definitions using the RunWorkflow and WaitForWorkflow Activities that are included out of the box (if you look at the LabDefaultTemplate it does this).
A more elegant solution would be to do it in one workflow using the AgentScope activity to separate out the sections of the workflow that need to run on different specific agents. If you look at the DefaultTemplate most of it is wrapped in a single AgentScope activity (labeled Run On Agent), but you could split it out into a couple AgentScope activities that are called in sequence (or in parallel if possible).
I'd like to publish certain files for each build regardless of success/failure. In my case I want to publish a report generated from a JUnit RunListener implementation we've implemented, however I would also find it useful to publish additional log files, and any other specific files I am interested in.
I know TeamCity does this out of the box. Is it possible with Hudson? The DocLinks plugin and the "Archive the artifacts" checkbox only seem to work for successful builds.
Thanks in advance
The "archive the artifacts" feature kicks in even for failed builds. If it doesn't, I consider that a serious bug. Which version of Hudson are you using?
I thought so far, that Hudson marks a job as unstable instead of failed when running the junit tests.
However, If you don't want to create your own plugin, you might use a workaround. The basic idea is to hide from Hudson the initial failure and do whatever needs to be done before telling Hudson that there is a problem.
There are different approaches.
Always hide errors from Hudson, the job will never fail, however, the report will always be published. The disadvantage is, that you need to monitor the jobs/reports since Hudson will not tell you that there is a problem.
capture the error outside of Hudson, than do your publish outside of Hudson, and than tell Hudson that there was an error and let Hudson do the rest.