I am using Fed Ex Shipping Web Service but getting following error on Running the application.
Unable to obtain courtesy rates.
I am using Fed Ex test account and fedex meter number. I am using shipServiceDefination.wsdl.
Can any body suggest whats the problem?
I have the same issue. First times all my test requests works properly, but then I start to get similar messages. I suppose that fedex test web service either not works sometimes or have limitation for test requests...
There is nothing wrong in the code this is mainly due to website issue. I tried the same thing after few hours and it was working perfectly.
Short answer
Wait a while and retry again; it's quite possibly a FedEx Sandbox test environment issue.
Note that the FedEx Sandbox environment might be unstable during your testing, and you might need to use FedEx API mocks instead of the Fed Ex Sandbox environment (either built in-house using Wiremock or ready-made by a vendor).
Long answer
The FedEx Sandbox has numerous stability and test data problems.
If you are performing a one-off manual integration test with the rates FedEx API, then using the FedEx Sandbox should be sufficient, and you can re-try your request, and it "hope" be successful after a while.
If, however, you are running automated regression or integration tests on a schedule or per commit, then the instability of the environment might hurt your testing. For example, you might see flaky tests and builds and have to spend time investigating them even though there is nothing wrong with your code or tests, and it's just an issue with the FedEx Sandbox API.
To resolve the issue with FedEx Sandbox environment stability, you have three options, which are essentially about using test-doubles instead of the actual FedEx Sandbox API:
Create and use function or method mocks in your code instead of using the FedEx Sandbox. For example, Mockito in Java or uniuttest.mock in Python. You will have to write the FedEx Mockito mocks yourself. And it comes with several tradeoffs. This is a popular option for developers that have time on their hands and can build solutions internally, and don't work on a tight deadline.
Create over-the-wire mocks with tools like Wiremock or Mountebank instead of using the FedEx Sandbox. There is a list of tools like that on Wikipedia. Again, the issue is that you have to build those over-the-wire mocks, which can be problematic if it's more than one API and you have a lot of work on your plate anyway.
Use ready-made FedEx API mocks like the one from Traffic Parrot instead of using the FedEx Sandbox. The advantage is that experts create them and can use them within minutes. Just copy their mock API URL and use it instead of the FedEx one. Good idea if you are on a tight deadline. You will have to pay for using them, which can sometimes be a downside of this option.
Related
I've been learning Travis CI and I want to use it to help automate tests on a MEAN application, then deploy it. However, there are some ways to go about this.
After reading, I learned I can create two separate repositories, thus maintaining two separate applications: a client application and a backend application. Since they are separate repositories, I can have separate .travis.yml files on each and perform continuous integration on the client application and backend application. However, I need advice on this approach because I have questions:
For the client app, I have to write tests. Since I'll be using angular, I want to test responsiveness and if components are working as intended. The client application also has to communicate with the backend application and I want to see if it is properly getting the correct results (such as clicking a button triggers a GET request and see if I'm getting the correct response body). Since the client app is on a separate repository, and when I build it on TravisCI, how will I connect the client application to the backend application if it exists on a separate repository?
I read around and I can use submodules in git. Thus, the client application and the backend application can be submodules for a 'master repository'. Therefore, how will the trigger in TravisCI work? Will I have separate travis.yml files in each submodule, or will I have to have one in the "master repository"?
If I were to get everything to work properly and have the client application and backend application both successfully deploy and the two are hosted on different servers, how will I fix the cross-domain issue?
The other approach is to host the static files produced by ng build --prod and have the node backend application host them. When Travis CI is triggered, I can first build the node backend application and run the tests on it first and then run the tests on the angular client application. After all of the tests are passed, where do I deploy? I know I have to deploy the node application since it will host the static files, so I how exactly will I deploy the backend application in Travis CI?
I know this is going to push it, but I'll ask it anyway. In the future, I want to learn how to implement microservices, and I want to use Nginx for the purpose of load balancing. How will I go about that? Docker can help me create a production environment where I can see if the Nginx server and node application are working well, but how do I include that in Travis CI?
If my question is a bit vague, please let me know what parts of it are vague so I can edit it that way I can make more sense of what I'm asking for. Thank you, and I look forward to an answer :)
Question is ultra-broad. You should solve one problem at a time, because by the time you solve 1 and 2 I doubt that 3 will be your only concern, and all of these issues are not really related.
try spending a bit of time reading Travis CI documentation, but also how to write tests and what different types of tests will do for you. Your issue is less about Travis than about what are unit tests vs. what are integration tests. So write simple standalone tests for your frontend, simple standalone tests for your backend, maybe run integration tests manually for a while, and when it becomes a real issue, then you will have better knowledge of how everything works together and you will find a way. Long story short: there is no single best way to run integration tests and it mostly depends on many, many things in your app (how does it run, what type of DB do you use, etc.)
you should read about submodules. Perhaps you need them, perhaps not. There is no way to tell. You can use submodules with Travis CI, but you can also not use submodules. Depends on what you want to achieve. Focus on the end goal for your architecture, not on what Travis CI needs!
what cross-domain issue? Again, this is a very different problem, and probably not the most prominent one you will face. Since I have no idea what server technology you will use there is no way I can answer that question properly. If you use express, this may be what you are looking for: https://expressjs.com/en/resources/middleware/cors.html
General bit of advice: all of your questions boil down to experience. Try solving one problem at a time, get started with your project and when you hit a specific issue, it's much much easier to solve than asking about "microservices". There are many ways to do microservices right, each solving a different issue. Without any knowledge of what your application is about and what issues you want to solve, microservices may or may not be what you are looking for, but there are also many other components that can affect your stack. Just get started and don't think about all of this too much for now - it's better to have something soon that you can test and learn upon, than think for weeks about something that you will never get because it is only theory.
I'm in the phase of integrating cucumber tests for an existing application. The app interacts heavily with a backend. The simplest case being the registration of an user.
In order to make the tests repeatable, I cannot go against the (real) backend (for several reasons, one not being able to register two users with the same e-mail).
I'd like to know which options do I have to mock the backend behavior and deliver mocked responses. For unit testing I know Nocilla and several other frameworks. Integrating them of course does not work for calabash tests.
One alternative would be to have a real server running which I'd control from the calabash tests to control the networking. But that seems a bit overkill. Another option would be to have mock objects in the calabash target which I could control via the calabash backdoor mechanism.
I doubt that aren't the only options. So my question is: is there a more elegant way to do so?
As I received no other feedback until today, I'll answer my own question.
We opted for the way of creating a very simple mock for our backend. We used Sinatra, but a node.js or similar technique would have led to the same result. The mock can be controlled via a simple REST API.
In the step definitions we configure our mock backend appropriately for the running scenario. It's a bit of overhead, because the mock has to evolve with the real backend, but until today it feels like a robust solution.
I want to build an IOS app (both iphone and ipad) which support iCloud and dropBox; And also I need to write tests for that.
How should I do that to reduce the cost of tests?
And is there any sample code in any language which would do that?
It depends what you are looking for. You can use a Continuous Integration tool like Jenkins that allow you to build and to test iOS applications. You can read this article which will give context about it. If you are looking for a cloud provider in order to reduce the costs because you don't want to buy a new infrastructure on your end, there is a provider which allow you to build/test iOS applications on the cloud. See here how you can do this.
If you just need a development environment for some time, maybe doesn't make sense to buy new infrastructure when you can rent a service for just the time you need it. You should consider what is your best choice.
You can also use Selenium as an option for your end-to-end tests.
I'm trying to sift through the myriad of test solutions out there, and I'm not even sure if I'm headed the right direction. The story is: we're running a RESTful Web service, implemented as a Rails app, which backs our mobile clients. We're unit testing the Web service (of course), but that involves mocking out many parts of the application, for instance, the search stack (Apache SOLR).
Moreover, our tests don't (i.e. cannot!) cover critical routes such as the mobile sign-in/sign-on process, since that involves communication between the API application and the mobile website, where the user can enter credentials, e.g. for SSO (Janrain Engage). Hence, a standard Rails integration test won't do.
I realize that in theory, if the test suite is very well designed, where mocking only happens strictly at the those join points where the tests for the next layer start, then by unit or functional testing the service API and the mobile website separately, one could get the same test coverage. I find that in practice though, this is an illusion if you have several developers working on the test suite independently; I just admit that our unit tests are simply not that well designed. Particularly when exercising TDD I found that while the tests can drive the application code, the test code design is only tailored to the unit under test, resulting in a rather wildly grown test suite.
Another thing I found is that sometimes we didn't detect regressions purely using unit tests, where e.g. bad queries were sent to the SOLR server due to knock-on effects. That's why I thought the only true way to ensure that the entire stack works along the critical routes is to automatically end-to-end test it on a staging server before every deployment, i.e. having actual HTTP requests sent to the app.
My questions would be:
do you think this is a reasonable thing to do at all? I found very little information about end-to-end testing a live API on the Web, leaving me wondering whether I'm making any sense at all
which tools/setup would you suggest? We use Watir to run acceptance tests for our website, but it seems to be overkill for a Web service (no browser environment needed, no JS or anything UI-ish). Something as simple as a Ruby script even?
any general best practices or advice you can give me w.r.t. to designing such tests?
This might be of interest to you: http://groups.google.com/group/ruby-capybara/browse_thread/thread/5c27bf866eb7fad3
What you might want to to try is combining Cucumber (or similar) with one of the tools mentioned in the link above, so you can do something like
Given I have 2 posts
When I send "DELETE" to post with id 1
Then I should have 1 post
This way you can test the API's full stack and check the result.
We've faced similar problems lately, like testing only on the unit level was fast but not enough to spot integration related anomalies.
I really like Cucumber's gherkin syntax, the value for me in it is that we can run the exercise once and then make several expectations after with separate titles, like if they would be separate RSpec it blocks.
There is a gem called Turnip, which makes possible to write RSpec tests with the gherkin syntax. We have been using it for a while and I'm quite happy with it, we even started having less integration level defects.
I collected my experience regarding in a blog post: https://blog.kalina.tech/2019/10/end-to-end-testing-for-api-only-rails-apps-with-cucumber-syntax.html
I am working on a Rails app that allows you to create a configuration and then launch a server at EC2 with this configuration.
So far I've been using cucumber for BDD and was very happy with that. However, now I want to pick a configuration and actually launch the server. Due to cost and performance issues I don't want to actually launch a server every time I am running the cucumber features.
Are there any best practices for cases like this? I would like to keep the BDD up, but also don't want to spend too much time on working on an elaborate solution just to have feature descriptions for this. On the other hand I will have the same problems, when I will have to write Unit test for this.
When working on a rails app that required twitter integration, I found fakeweb to be extremely helpful. I've used it in conjunction with cucumber successfully.
I found that to support the BDD outside-in development style, I set fakeweb to disallow all web traffic and then added my faked-out web calls one at a time, as my tests failed. It seemed to fit right in with my BDD workflow.