Feature: Reintroduce FogBugz

[MadsNielsen]

We would like to re-introduce support for FogBugz.

Support for FogBugz was removed prior to release version 1.X.X.

FogBugz has an API that is described here. http://help.fogcreek.com/the-fogbugz-api

FogBugz API does not use Basic Authentication, all requests must tag on a API key as part of the request, which, when using their cloud solution is always https. (Good!)

FogBugz do not have a stand-alone product, you cannot host FogBugz yourself.

Also, if we want to use simple urls (Basically the query string) all ressponses are in XML. We will need to convert this XML into a ruby hash, which is very simple.

Work items:

1. Authentication, since we do not use any authentication, there needs to be a mechanism to avoid adding basic auth headers to the request
2. We need to covert the XML response into a ruby hash.

Solutions:

1. The long one: Create yet-another-configuration section auth with key none or basic . The short one: If pw or usr is not defined, assume no-auth, print warning to console.
2. Just use one of the many available ruby libraries to turn xml into ruby hashes.

[buep]

You need to write tests! And the same comments about issue description and workflows apply as my comment in:

https://github.com/Praqma/Praqmatic-Automated-Changelog/issues/63#issuecomment-236559443

[MadsNielsen]

Most of the requirements for this are already in place. I've got a simple test, that test the configuration part of fogbugz section. For me, what is missing in this case is a test with some mocked return data from FogBugz.

That is a small unit test, fogbugz works the same as jira.

[buep]

Which of the above solutions you suggested did you chose?

Which test scenarios do you have with Fogbugz?

[MadsNielsen]

1. I used the 'no-auth' easy solution with warning in console, fogbugz does not support basic auth (token security as part of the query string)
2. Theres a very simple XML library i used to convert output to ruby hash. (Oneliner... XmlSimple.xml_in...

The only scenario i have is that the configuration is parsed correctly and the task system is picked up and fails correctly. Otherwise it's identical to Jira. It's the same as with GitHub which makes it very simple to integrate, since they're all using REST api's and are very similar. My test scenario for fogbugz would likely just include a sample return snippet of fogbugz XML, to make sure that my model objects are created correctly. We could add a unit test that creates a report with that model object if that is required.

[buep]

I'm missing test scenarios around Fogbugz related to communication... if not responding, if timing out, if bad data received .... all these situation needs to be tested, either for fogbugz or in general and report decent error messages from PAC.

If Fogbugz have a version of their api, and you can actually see that, I'm okay with you stub the data. Then just make sure if the version for fogbugz data isn't as expected, we fail properly. That way we know it works in the future, or a least report decent error about the expected dataformat doesn't match and FB might have upgrade their api.

[MadsNielsen]

Right, we can attempt to implement these scenarios:

• 200 Ok, used mock data - Test model object
• 404 Not found (Invalid url)
• Bad data returned..mock data (broken xml)
• Unresponsive opening. Ruby has a default timeout of 60 seconds for opening connection. This test is trickier to implement because we'd need to mock the connection class to always throw the the Net::Timeout exception

[buep]

yep, good scenario. I want them. Make the general, so they can used for all the tasks systems. I guess only the 200 Ok and third with broken data is task specific.