Key Points

...

curl-flaviocopes.com-The curl guide to HTTP requests.pdf

Swagger - OpenAPI

Postman - API Test Tool

Free Postman account

jm9@gmail

...

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

...