Table of Contents |
---|
Key Points
- Postman now free for teams of 3 developers !!
References
Key Concepts
What Is The Difference Between Web Services and APIs
Web Services | API |
All web services are APIs. | All APIs are not web services. |
It supports XML. | Responses are formatted using Web API’s MediaTypeFormatter into XML, JSON, or any other given format. |
You need a SOAP protocol to send or receive data over the network. Therefore it does not have lightweight architecture. | API has a lightweight architecture. |
It can be used by any client who understands XML. | It can be used by a client who understands JSON or XML. |
Web service uses three styles: REST, SOAP, and XML-RPC for communication. | API can be used for any style of communication. |
It provides support only for the HTTP protocol. | It provides support for the HTTP/s protocol: URL Request/Response Headers, etc. |
API Testing types
- Validation Testing
- Functional Testing
- UI testing
- Load testing
- Runtime/ Error Detection
- Security testing
- Penetration testing
- Fuzz testing
- Interoperability and WS Compliance testing
More test tools
testing tools
...
https://github.com/postmanlabs/postman-app-support/issues/2646
Problem
Sending a request to some pages, keep getting the error 'Javascript is disabled on your browser. Please enable Javascript and refresh this page'. The page works on the browser but on Postman it comes up with that error. Initially thought it was the page so tried another and still keep getting the error
Solution
- Postman Version: 4.9.3
- App (Chrome app or Mac app): Mac app
- OS details: 10.12.2
- Is the Interceptor on and enabled in the app: No
- Did you encounter this recently, or has this bug always been there: N/A
- Expected behaviour: N/A
- Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app): N/A
- Screenshots (if applicable) N/A
...
Robot Framework is actively supported, with many industry-leading companies using it in their software development.
Robot Framework is open and extensible and can be integrated with virtually any other tool to create powerful and flexible automation solutions. Being open source also means that Robot Framework is free to use without licensing costs.
Robot Framework has easy syntax, utilizing human-readable keywords. Its capabilities can be extended by libraries implemented with Python or Java. The framework has a rich ecosystem around it, consisting of libraries and tools that are developed as separate projects.
...
Libraries contain framework functions
Libraries provide the actual automation and testing capabilities to Robot Framework by providing keywords. Several standard libraries are bundled in with the framework, and galore of separately developed external libraries that can be installed based on your needs. Creating your own libraries is a breeze.
Standard
Builtin
Provides a set of often needed generic keywords. Always automatically available without imports.
...
Now make a directory called "features/". In that directory create a file called "example.feature" containing:
# -- FILE: features/example.feature
Feature: Showing off behave
Scenario: Run a simple test
Given we have behave installed
When we implement 5 tests
Then behave will test them for us!
Make a new directory called "features/steps/". In that directory create a file called "example_steps.py" containing:
# -- FILE: features/steps/example_steps.py
from behave import given, when, then, step
@given('we have behave installed')
def step_impl(context):
pass
@when('we implement {number:d} tests')
def step_impl(context, number): # -- NOTE: number is converted into integer
assert number > 1 or number == 0
context.tests_count = number
@then('behave will test them for us!')
def step_impl(context):
assert context.failed is False
assert context.tests_count >= 0
Run behave:
$ behave
Feature: Showing off behave # features/example.feature:2
Scenario: Run a simple test # features/example.feature:4
Given we have behave installed # features/steps/example_steps.py:4
When we implement 5 tests # features/steps/example_steps.py:8
Then behave will test them for us! # features/steps/example_steps.py:13
1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 0 skipped
3 steps passed, 0 failed, 0 skipped, 0 undefined
...
trader_is_alerted_of_status.story.
Given a stock of symbol STK1 and a threshold of 10.0 When the stock is traded at 5.0 Then the alert status should be OFF |
...
Configure Stories with data scenarios
At the heart of the JBehave running of stories lies the Embedder, which provides an entry point to all of JBehave's functionality that is embeddable into other launchers, such as IDEs or CLIs. JBehave complements the Embedder with an Embeddable which represents a runnable facade to the Embedder.
JBehave allows many different ways to configure Embeddable Java classes that allow the parsing and running of textual stories.
JBehave provides two main Embeddable implementations:
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
public class TraderStoryRunner { @Test public void runClasspathLoadedStoriesAsJUnit() { // Embedder defines the configuration and candidate steps Embedder embedder = new TraderEmbedder(); List<String> storyPaths = ... // use StoryFinder to look up paths embedder.runStoriesAsPaths(storyPaths); } @Test public void runURLLoadedStoriesAsJUnit() { // Embedder defines the configuration and candidate steps Embedder embedder = new URLTraderEmbedder(); List<String> storyPaths = ... // use StoryFinder to look up paths embedder.runStoriesAsPaths(storyPaths); } } |
where the TraderEmbedder/URLTraderEmbedder define the configuration using the loading from the classpath and URL resources, respectively. E.g.:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
public class TraderEmbedder extends Embedder { @Override public EmbedderControls embedderControls() { return new EmbedderControls().doIgnoreFailureInStories(true).doIgnoreFailureInView(true); } @Override public Configuration configuration() { Class<? extends TraderEmbedder> embedderClass = this.getClass(); return new MostUsefulConfiguration() .useStoryLoader(new LoadFromClasspath(embedderClass.getClassLoader())) .useStoryReporterBuilder(new StoryReporterBuilder() .withCodeLocation(CodeLocations.codeLocationFromClass(embedderClass)) .withDefaultFormats() .withFormats(CONSOLE, TXT, HTML, XML) .withCrossReference(new CrossReference())) .useParameterConverters(new ParameterConverters() .addConverters(new DateConverter(new SimpleDateFormat("yyyy-MM-dd")))) // use custom date pattern .useStepPatternParser(new RegexPrefixCapturingPatternParser( "%")) // use '%' instead of '$' to identify parameters .useStepMonitor(new SilentStepMonitor()); } @Override public InjectableStepsFactory stepsFactory() { return new InstanceStepsFactory(configuration(), new TraderSteps(new TradingService()), new BeforeAfterSteps()); } } |
Running Remote Stories
JBehave supports running both local and remote stories. To run remote stories, we need to use a URL-based loader with an appropriate remote code location. The difference w.r.t. the local run is minimal:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
public class RemoteTraderStories extends TraderStories { @Override public Configuration configuration() { return super.configuration() .useStoryLoader(new LoadFromURL()) .useStoryReporterBuilder( new StoryReporterBuilder() .withCodeLocation(codeLocationFromURL("http://jbehave.org/reference/examples/stories/")) .withDefaultFormats() .withFormats(CONSOLE, TXT, HTML, XML)); } @Override protected List<String> storyPaths() { // Specify story paths as remote URLs String codeLocation = codeLocationFromURL("http://jbehave.org/reference/examples/stories/") .toExternalForm(); return asList(codeLocation + "and_step.story"); } } |
Ignoring Failures Running Stories
By default, the story runners are configured to fail-fast, i.e. the execution will stop at first failed story (but will complete execution of the all the scenarios in the story first). To allow the generation of a complete stories view (reporting how many stories failed), the runners need to be enabled to run stories with ignoreFailureInStories flag set to true. In this way, all stories will run and the failure will be assessed only during the view generation. If any stories failed, the build will fail correspondingly. Should the need to ignore failure in the view arise (although generally not recommended), one can set the ignoreFailureInView flag to true.
View Reports
https://jbehave.org/reference/stable/reporting-stories.html
...