26 Jan 2019
What Is Behavior Driven Testing?
Behavior Driven Testing (BDT) is an uncommon term in software testing/development compared to Behavior Driven Development (BDD). 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.
BDT is the best choice when you want to show your business point of view and the requirements of the product. To spread out the product ideas, BTD uses very easily understandable language to make sure everyone on the team does not miss anything, even they are non-technical people. Hence, people who are in charge of business analysis and product management can actively join the testing process. Behavior Driven Testing is gaining momentum as lots of organizations are looking at it as a solution to their automation and collaboration challenges. The BDT framework has been successfully implemented by various QA teams in various domains.
BDD-cycle.
Why Behavior Driven Testing Originated
One of the common downsides when using these frameworks is that it is hard for non-technical people like business analysts and management people to read and understand the test cases, but behavior driven testing can handle it. It has helped to fill the communication gap by writing the test cases in natural language.The scenarios are written to build up a clear understanding of the desired behavior through discussion with stakeholders.
Thanks For Reading It .
23 Jan 2019
Welcome To The New Revolutionary Era of API’s !
First of all, I want to clear that GraphQL is not any database most of the people think!
GraphQL.
Choosing GraphQL gives you easy to design and amazing to consume API. It also rewards you with effortless consistency between the APIs. By its nature, GraphQL is contract-driven and comes with introspection, which is something REST lacks out-of-the-box.
The cost you pay is that your clients have to read the docs (GraphQL schema) at the development time and hardcode the affordances (queries and mutations). This hardcoding of the development-time knowledge leads to clients tightly coupled to the server, but the same also applies to so-called-REST APIs.
Using GraphQL also leaves you vulnerable to what HTTP protocol and the whole internet infrastructure already solved: Scaling, performance, network communication mechanics, and concepts like content, language negotiation, and many others. Some of these can be “added” to a GraphQL API but are not included in-the-box. Adding the functionality that otherwise comes with HTTP leads to bike-shedding. And unfortunately, these home-made-solutions destroys the genius of consistency between GraphQL APIs.
Conclusion
Some similarities and differences already:
- Similar: Both have the idea of a resource, and can specify IDs for those resources.
- Similar: Both can be fetched via an HTTP GET request with a URL.
- Similar: Both can return JSON data in the request.
- Different: In REST, the endpoint you call is the identity of that object. In GraphQL, the identity is separate from how you fetch it.
- Different: In REST, the shape and size of the resource is determined by the server. In GraphQL, the server declares what resources are available, and the client asks for what it needs at the time.
20 Jan 2019
Using GitHub for issue tracking
It’s super simple to use for versioning, hosting, and getting new and updated code to your website. Beyond that, with a recent update to the web interface
Organizing our issues with Milestones
Without the ability for users and contributors to file issues on GitHub, I’m not sure we would have caught all the bugs, improvements, and feature requests that we did. With well over hundreds of issues closed on Bootstrap, because we had the ability to tag each issue and assign them to a milestone.
Setting expectations
The milestone feature is great for two reasons: my own sanity and transparency for everyone else. Each milestone has represents a new release and helps set expectations for others when dates are assigned to them. Setting expectations on an open-source project like Bootstrap is immensely useful for all involved. It shows people that this is a trusted and evolving endeavor; it’s going to be around for awhile.
Driving responsibility
It’s been a blast to talk through ideas, push back on others, and help people solve problems. I love every moment of it.If you have the chance–even if you’re working in a closed, private repo–give the issue tracking and milestone features of GitHub a go. You’ll be thoroughly impressed and should see a noticeable increase in productivity.
17 Jan 2019
The Difference Between REST and SOAP APIs
This overview will help you understand the differences between REST and SOAP APIs, and how they are used in integrations.
The words “web services” mean many things to people with different fields. For general users, it is about using online services, like surfing the internet, but for developers and webmasters, it has different meanings. Overall it is a broad term that tells us how the communication between two different set of devices or applications held over the World Wide Web (WWW).
This communication system can be categorized into two types, namely Simple Object Access Protocol or SOAP, and Representational State Transfer or REST.
Quite often both are considered to be the terms with same meanings but the how both works and what tools both use for communication purposes creates the fine line between two. Before highlighting the differences between two, it merits to discuss what both actually are.
What Is a REST API?
REST is basically an architectural style of the web services that work as a channel of communication between different computers or systems on the internet. The term REST API is something else.
Those application programming interfaces that are backed by the architectural style of REST architectural system are called REST APIs. REST API compliant web services, database systems, and computer systems permit requesting systems to get robust access and redefine representations of web based resources by deploying a predefined set of stateless protocols and standard operations.
REST.
By these protocols and operations and redeploying the manageable and updatable components without causing the effect on the system, REST API systems deliver fast performance, reliability, and more progression.
What Is a SOAP API?
SOAP is a standard communication protocol system that permits processes using different operating systems like Linux and Windows to communicate via HTTP and its XML. SOAP based APIs are designed to create, recover, update and delete records like accounts, passwords, leads, and custom objects.
These offers over twenty different kinds of calls that make it easy for the API developers to maintain their accounts, perform accurate searches and much more. These can then be used with all those languages that support web services.
SOAP APIs take the advantages of making web based protocols such as HTTP and its XML that are already operating the all operating systems that are why its developers can easily manipulate web services and get responses without caring about language and platforms at all.
Differences:
-
REST API has no has no official standard at all because it is an architectural style. SOAP API, on the other hand, has an official standard because it is a protocol.
-
REST APIs uses multiple standards like HTTP, JSON, URL, and XML while SOAP APIs is largely based on HTTP and XML.
-
As REST API deploys multiple standards, so it takes fewer resources and bandwidth as compared to SOAP that uses XML for the creation of Payload and results in the large sized file.
-
The ways both APIs exposes the business logics are also different. REST API takes advantage of URL exposure like @path(“/WeatherService”) while SOAP API use of services interfaces like @WebService.
-
SOAP API defines too many standards, and its implementer implements the things in a standard way only. In the case of miscommunication from service, the result will be the error. REST API, on the other hand, don’t make emphasis on too many standards and results in corrupt API in the end.
-
REST API uses Web Application Description Language, and SOAP API used Web Services Description language for describing the functionalities being offered by web services.
-
REST APIs are more convenient with JavaScript and can be implemented easily as well. SOAP APIs are also convenient with JavaScript but don’t support for greater implementation.