Page Comparison

Key Points

...

...

Postman Errors at Runtime

Many runtime errors can be analyzed in the Postman client by:

1. validating the url for the host app is correct
2. ensuring the request url is correct with the substituted values for any values
3. viewing Postman console for the request / response data actually sent and received
4. viewing Postman logs for requests/ responses
5. checking headers, authentication methods on the test case
6. checking pre-request scripts
7. checking the test scripts for potential errors based on missing data in the response ( try removing the post tests temporarily and re-run the test )

Resolving an issue in the Deprecated Chrome Postman Plugin for Javascript support in web page accessed

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

1. Postman Version: 4.9.3
2. App (Chrome app or Mac app): Mac app
3. OS details: 10.12.2
4. Is the Interceptor on and enabled in the app: No
5. Did you encounter this recently, or has this bug always been there: N/A
6. Expected behaviour: N/A
7. 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
8. Screenshots (if applicable) N/A

For some reason, I need run javascript and submit forms in Preview. I know postman doesn't support it for security (CSP). So I inspected postman's source code via DevTools, and finally I found

131078                 { className: 'response-body-iframe-viewer' },
131079                 _react2.default.createElement('iframe', {
131080                   className: 'response-body-viewer-preview',
131081                   sandbox: '' // https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe#attr-sandbox
131082                   , src: this.props.src
131083                 })

in /Applicatoins/Postman.app/Contents/Resources/app.js

Then I modify line 131081 to
sandbox: 'allow-forms allow-scripts'

relaunch postman, it works!

I think it's may not safe when using postman under sandbox: 'allow-forms allow-scripts' all the time. So maybe we could add a button to postman's preferences settings, then we can enable/disable it as needed.

Automating API tests in Postman

...

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.

...

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:

...

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.:

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:

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

...