WebService, API and their Difference

Web service (WS)

• A service offered by an electronic device to another electronic device, communicating with each other via the World Wide Web, or
• A Web service is a server running on a computer device, listening for requests at a particular port over a network, serving web documents (HTML, JSON, XML, Images), and creating web applications services, which serve in solving specific domain problems over the web (www, internet, HTTP)

In a Web service a Web technology such as HTTP — originally designed for human-to-machine communication — is used for transferring machine-readable file formats such as XML and JSON.

In practice, a Web service commonly provides an object-oriented Web-based interface to a database server, utilized for example by another Web server, or by a mobile app, that provides a user interface to the end user. Many organizations that provide data in formatted HTML pages will also provide that data on their server as XML or JSON, often through a Web service to allow syndication, for example, Wikipedia's Export. Another application offered to the end user may be a mashup, where a Web server consumes several Web services at different machines and compiles the content into one user interface.

The term "Web service" describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet Protocol backbone. XML is the data format used to contain the data and provide metadata around it, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI lists what services are available.

A Web service is a method of communication between two electronic devices over a network. It is a software function provided at a network address over the Web with the service always on as in the concept of utility computing.

Many organizations use multiple software systems for management. Different software systems often need to exchange data with each other, and a Web service is a method of communication that allows two software systems to exchange this data over the Internet. The software system that requests data is called a service requester, whereas the software system that would process the request and provide the data is called a service provider.

Different software may use different programming languages, and hence there is a need for a method of data exchange that doesn't depend upon a particular programming language. Most types of software can, however, interpret XML tags. Thus, Web services can use XML files for data exchange.

Rules for communication between different systems need to be defined, such as:

• How one system can request data from another system.
• Which specific parameters are needed in the data request.
• What would be the structure of the data produced. (Normally, data is exchanged in XML files, and the structure of the XML file is validated against an .xsd file.)
• What error messages to display when a certain rule for communication is not observed, to make troubleshooting easier.

All of these rules for communication are defined in a file called WSDL (Web Services Description Language), which has a .wsdl extension.

Application Programming Interface (API)

                              

API is an interface or communication protocol between a client and a server intended to simplify the building of client-side software. It has been described as a “contract” between the client and the server, such that if the client makes a request in a specific format, it will always get a response in a specific format or initiate a defined action.

An API may be for a web-based system, operating system, database system, computer hardware, or software library.

An API specification can take many forms, but often includes specifications for routines, data structures, object classes, variables, or remote calls.POSIX, Windows API and ASPI are examples of different forms of APIs. Documentation for the API usually is provided to facilitate usage and implementation.

Popular API Examples

ProgrammableWeb, a site that tracks more than 15,500 APIs, lists Google Maps, Twitter, YouTube, Flickr and Amazon Product Advertising as some of the the most popular APIs. The following list contains several examples of popular APIs:

1. Google Maps API: Google Maps APIs lets developers embed Google Maps on webpages using a JavaScript or Flash interface. The Google Maps API is designed to work on mobile devices and desktop browsers.

2. YouTube APIs: YouTube API: Google's APIs lets developers integrate YouTube videos and functionality into websites or applications. YouTube APIs include the YouTube Analytics API, YouTube Data API, YouTube Live Streaming API, YouTube Player APIs and others.

3. Flickr API: The Flickr API is used by developers to access the Flick photo sharing community data. The Flickr API consists of a set of callable methods, and some API endpoints.

4. Twitter APIs: Twitter offers two APIs. The REST API allows developers to access core Twitter data and the Search API provides methods for developers to interact with Twitter Search and trends data.

5. Amazon Product Advertising API: Amazon's Product Advertising API gives developers access to Amazon's product selection and discovery functionality to advertise Amazon products to monetize a website.

Ref: Wikipedia.com

Ref: Webopedia.com

API vs Web Service

API and Web service serve as a means of communication. The only difference is that a Web service facilitates interaction between two machines over a network. 

An API acts as an interface between two different applications so that they can communicate with each other. An API is a method by which the third-party vendors can write programs that interface easily with other programs. 

A Web service is designed to have an interface that is depicted in a machine-processable format usually specified in Web Service Description Language (WSDL). Typically, “HTTP” is the most commonly used protocol for communication. Web service also uses SOAP, REST, and XML-RPC as a means of communication. 

API may use any means of communication to initiate interaction between applications. For example, the system calls are invoked using interrupts by the Linux kernel API. An API exactly defines the methods for one software program to interact with the other. When this action involves sending data over a network, Web services come into the picture. An API generally involves calling functions from within a software program.

In case of Web applications, the API used is web based. Desktop applications such as spreadsheets and word documents use VBA and COM-based APIs which don’t involve Web service. A  server application such as Joomla may use a PHP-based API present within the server which doesn’t require Web service.

A Web service is merely an API wrapped in HTTP. An API doesn’t always need to be web based. An API consists of a complete set of rules and specifications for a software program to follow in order to facilitate interaction. A Web service might not contain a complete set of specifications and sometimes might not be able to perform all the tasks that may be possible from a complete API.

The APIs can be exposed in a number of ways which include: COM objects, DLL and .H files in C/C++ programming language, JAR files or RMI in Java, XML over HTTP, JSON over HTTP, etc. The method used by Web service to expose the API is strictly through a network.

Ref: https://medium.com/@programmerasi/difference-between-api-and-web-service-73c873573c9d

NUnit Framework

                                        

NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 3, has been completely rewritten with many new features and support for a wide range of .NET platforms.

NUnit is a test Framework like JUnit, where you can define your tests cases, tests suites and assertions. NUnit can run all the tests and show you a report. NUnit, like JUnit, enables test-driven development. NUnit tests can also run in Taurus.

The use of NUnit framework

1. NUnit runs very well with .NET programming languages.
2. It is open source and it is free.
3. It is easy to integrate it with testing projects.
4. NUnit works with many integrated runners including Resharper and TestDriven .NET.
5. NUnit has frequent version updates.
6. NUnit has a graphical user interface.
7. Very easy integration with Visual Studio and other IDEs.

NUnit is basically composed of attributes, or annotations. These indicate to the framework to execute the tests that are implemented in the class, and also how to interpret them. Annotations tell the framework how to interpret the code. After this code is compiled, a dll file is generated that can be executed through a console or using the graphic interface. Tests also include assertions that allow checking and comparing values.

Important NUnit Annotations

The NUnit annotations are very easy to use: just add the annotation between brackets before the method declaration. With the annotation you can define the test: behavior (specifying Setup or TearDown method), assertions for example performance assertions like MaxTime method, and information like the Category method.

Annotation	Usage
Category	Specifies one or more categories for the test
Culture	Specifies cultures for which a test or fixture should be run
Indicates	Indicates that a test should be skipped unless explicitly run
Ignore	Indicates that a test shouldn't be run for some reason
MaxTime	Specifies the maximum time in milliseconds for a test case to succeed
OneTimeSetUp	Identifies methods to be called once prior to any child tests
OneTimeTearDown	Identifies methods to be called once after all child tests
Platform	Specifies platforms for which a test or fixture should be run
Random	Specifies generation of random values as arguments to a parameterized test
Repeat	Specifies that the decorated method should be executed multiple times
Retry	Causes a test to rerun if it fails, up to a maximum number of times
TearDown	Indicates a method of a TestFixture called immediately after each test method
Test	Marks a method of a TestFixture that represents a test
TestCase	Marks a method with parameters as a test and provides inline arguments
Timeout	Provides a timeout value in milliseconds for test cases
SetUp	Indicates a method of a TestFixture called immediately before each test method

NUnit Test Results

NUnit provides a console mode, the nunit-console, which facilitates its use in the continuous integration process. In the console, the pass-fail results are provided immediately and no subjective human judgments or interpretations of test results are required.

NUnit also has a graphical user interface, similar to the one used in JUnit, which it makes it easy to use for JUnit users. In the GUI you can see the execution of the tests, the test that is running and how many tests succeeded and failed.

Ref: NUnit.org

      blazemeter.com

Gherkin in Software Testing

Gherkin

                   

Gherkin is a domain-specific language used in Behaviour Driven Development to describe the business behaviour that should be modeled by the software being developed.

Behavior-Driven Development (BDD) has taken the software development world by storm – bringing Product, Development, and QA stakeholders together to ensure effective communication. The end result is a streamlined process that yields better results: features that customers actually need, higher quality products, and less time fixing issues later in the cycle.

Many teams practicing BDD use the Gherkin (“Given-When-Then”) format, which is written in plain-English, making it easy to understand regardless of technical expertise. Gherkin scenarios can easily run as automated tests using a tool like Cucumber, making descriptive reporting after automation test runs easy to share.

Gherkin is a plain text language that uses keywords, indentation and formatting to describe software specifications in terms of features, scenarios and steps.

Definitions for these components are written in a .feature file. Each .feature file should contain just one feature definition, followed by one or more scenarios. Each scenario has a number of steps explained using a Given-When-Then structure.

Use of Gherkin

There are many good reasons to use Gherkin. Possibly the three most important are:

1. It encourages teams to write and maintain ‘living documentation’, avoiding the typical pattern of: write documents, forget about them, write tests, forget about them.
2.  It can be used as the driver and foundation for your automated tests, helping to build a positive feedback loop between documentation, application development, test development and execution, and status reporting.
3.  It acts as a language bridge between business users, developers and testers, who should all be able to understand what has been explained in the documentation.

Gherkin provides a framework we can use to define what the end-user should expect from the features we’re developing, written in a way that everyone in the team can understand. These expectations should be defined clearly with detailed examples that leave no ambiguity regarding the acceptance criteria required by the business user to validate the end product.

What is a Feature

A feature file begins with the title of the feature introduced by the keyword “Feature:” followed by a short description of what the feature should do. Note that this text is usually not processed by any tools downstream and is generally used to convey information to the business users, developers and testers.

It’s important to understand that the description following the title should focus on the value of the feature to the business and the benefits it will deliver to the business end-users. It should not include any information about the implementation of lower-level functionality. Think of it as answering the questions “Who is this for?” and “Why should they want it?”

The aim is to have just one feature defined per feature file, so you’ll end up with many small files rather than a few large ones. This way it will be easier to process and organise these files downstream as features are implemented.

What is a Scenario

Next in the feature file comes the scenario definition. Each feature may have many scenarios. The title is demarcated by the keyword “Scenario:”. You have the option of writing a short description of the scenario after the title and before the first “Given:” statement. This description is sometimes called the ‘scenario brief’.

Scenarios should capture the users’ interaction with the system and the expectations they should have for the feature. However, to explain a feature fully usually requires many scenarios in order to account for all the possible permutations of use cases.

The details of the scenario’s starting point, actions and completion point are defined in the form of ‘steps’.

3 Steps in Gherkin

                         

Each scenario is made up of a number of steps. The starting point is indicated by the keyword “Given:”, the actions that are completed are indicated by “When:”, and the keyword “Then:” introduces the expected outcome or completion point. This Given-When-Then construct is the backbone of the Gherkin language.

1. Given Steps

The ‘Given’ statement sets the context for the scenario – the known state that needs to be set up before the scenario is executed. It’s important to get the starting point correct because the automated tests being driven from the feature files depend on the system under test being in the correct state before the test steps are executed. 

The purpose of the Given step is to define the known state in enough detail for the automated tests to run reliably. No assumptions should be made and no Given statements should be left out.

2. When Steps

The ‘When’ steps define the actions performed by the feature and the events that take place as a result. In the automated testing domain, the When steps are the test steps that need to be executed. These will be interpreted by the test automation tool to be run as test actions to simulate the end user’s interactions with the software.

3. Then Steps

The ‘Then’ steps define the expected state of the system after the ‘When’ steps have been completed. In our case, they are the expected test results. These statements should describe the conditions that the user would see. Because we’re following BDD principles, acceptance criteria should be expressed from the perspective of the business or end-user.

Use of Gherkin in Automating Tests

One of our main reasons for using Gherkin is to facilitate automated testing. The .feature files containing the application use case scenarios can be used as inputs to your automated testing system. A scenario can be turned into a test that will be used to verify the delivered feature against its acceptance criteria.

If the acceptance test fails, then either the acceptance criteria are incorrect and need updating, or the software does not correctly deliver the outcomes required of it. By implementing these acceptance tests as automated tests we can increase the speed of the feedback loop and provide the capability to run the tests frequently and on-demand.

Ref: www.automated-testing.com

Ref: smartbear.com

                             

Specflow in Automation Testing

                                         

What is Specflow?

Specflow is a testing framework supporting BDD practices in .NET framework. It’s an open source framework hosted on GitHub. It aids in using ATDD (Acceptance test driver development) for .NET Applications. With this, we can define scenario in plain English defined by Gherkin language that is clearly understandable by anyone.

Use SpecFlow to define, manage and automatically execute human-readable acceptance tests in .NET projects. Writing easily understandable tests is a cornerstone of the BDD paradigm and also helps build up a living documentation of your system.

SpecFlow is open source and provided under a BSD license. As part of the Cucumber Family, SpecFlow uses the official Gherkin parser and supports the .NET framework, Xamarin and Mono.

SpecFlow integrates with Visual Studio, but can be also used from the command line (e.g. on a build server). SpecFlow supports popular testing frameworks: MSTest v2, NUnit 3 and xUnit 2.

SpecFlow+ adds additional functionality to SpecFlow, such as Visual Studio Test Explorer integration, a dedicated test runner with advanced test execution options, execution reports (HTML, XML, JSON) and much more.

The essence in three easy steps

                                     

Spep 1: Specify

Describe the behavior of your system using human-readable syntax. Define specifications in the problem domain using the language of your stakeholders and build up a living documentation of your system

Step 2: Automate

Bind your test specifications to your application code to automate the testing of your system. Ensure that all your tests pass!

Step 3:  Enjoy!

Relax in the knowledge that SpecFlow will automatically identify breaking changes covered by your tests. Cut down on forensic development and enjoy the peace of mind that comes from knowing exactly what your software does and is supposed to do – even months later.

Ref: Specflow.org

Behavior-Driven Development Framework

Behavior-Driven Development (BDD)

According to BDD Framework creator Dan North: BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Behavior-driven development (BDD) 

Is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project.  It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes. Test scripts have long been a popular application of DSLs with varying degrees of sophistication. BDD is considered an effective technical practice especially when the "problem space" of the business problem to solve is complex.

It is an extension of test-driven development:  development that makes use of a simple, domain-specific scripting language. These DSLs convert structured natural language statements into executable tests. The result is a closer relationship to acceptance criteria for a given function and the tests used to validate that functionality. As such it is a natural extension of TDD testing in general.

BDD focuses on:

•         Where to start in the process
•         What to test and what not to test
•         How much to test in one go
•         What to call the tests
•         How to understand why a test fails

BDD is about rethinking the approach to unit testing and acceptance testing in order to avoid issues that naturally arise.  many people developed BDD frameworks over a period of years, finally framing it as a communication and collaboration framework for developers, QA and non-technical or business participants in a software project.

Ref: Wikipedia