Unit testing is too far inside the system. Integration testing of groups of components is closer, but not quite.More specifically, let’s go back and understand how we defined our use cases. There are two main approaches to use cases. SMART, and INVEST. While there’s supposedly differences between them, they’re not all that important. The important part to remember is that we have a process for identifying what is important and valuable to our customer, how we’ve defined it,
- SMART – Specific, Measurable, achievable, relevant and time-boxed.
- INVEST – Independent, Negotiable, Valuable,Estimable,Small and testable. Behaviour-Driven Development (BDD) is a second-generation, outside-in, pull-based, multiple-stakeholder ,multiple-scale, and high-automation agile methodology.
BDD validates “working” software based on the external behaviour of the system, preferably in an automated fashion.
What it boils down to is the external behaviour, what you expect. Notice that this does not talk about functions, databases, architectures or anything else. This is entirely from the customer’s perspective. You can see what they see from beginning to end. - BDD testing
As a [role], I want[feature] so that [benefit]. - As an anonymous user,I want to log in so that I can create a repository to store my code
BDD in Practice
- Give [condition], when I [action], then [result].
- Given I am an Authentical user, when I try to create a repository, then I get a new repository.
Gherkin Syntax:
The point of it is these four keywords: given, when, then, and and.
These keywords let us describe conditions define the actions we plan to take, describe the results, and using and, group them together to make sure things make sense. Now let’s take another look at our original use cases. Not surprisingly, each segment is clear. We can clearly see where our preconditions are, the actions which change the state of the system, and our result. Now enough talk. Let’s get things installed and start working.
- Given I am an anonymous user, when I submit a valid username and password, then I want to be authenticated.
- Given I am an unauthenticated user, when I try to create a repository, then I Get a new repository.
Setup:
- PHP 7.* version
- WebStorm IDE
Run this command:
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'a5c698ffe4b8e849a443b120cd5ba38043260d5c4023dbf93e1558871f1f07f58274fc6f4c93bcfd858c6bd0775cd8d1') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
Once done run below command:
php composer.phar require behat/behat 3.*
vendor/bin/behat -V
vendor/bin/behat --init
Reference Link: https://getcomposer.org/download/
Folder Layout:
Variety Authentication Options
– Username and password
– API keys/tokens
– OAuth
Which option do we use?
username and password and the API keys are the easiest to automate, by far, because you create those in advance, and you have them for the life of the account. OAuth is usually a little more challenging, because the user is involved in the process. In our case, let’s use the username and password approach that GitHub implements
Response codes and then get into the particulars. First are the 100 series. It’s rare that you’ll ever see these in the wild, let alone in APIs, so don’t worry about them. Next are the 200s and they’re used to describe some form of success. The 300 series are used to tell the client application whether it’s a web browser or even cURL, that the thing is looking for is now in a new location and here’s where to get it. The 400 series are used to describe errors and, unfortunately, these are client errors so they’re probably our fault. The final group are the 500s and they describe server errors. If you see one of these, there’s literally nothing you can do about it. The problem is server side and you just have to wait. Here are the response codes for the 200s that matter. The first, we know: 200 OK. Next, the 201 is used primarily as a result of a post-request when we’ve created something successfully. The 204 is used when we delete something successfully. The 400s are more complex, but one place where people often get confused is a 401 versus a 403 versus a 404. In normal terms, a 401 means the user is not authenticated. A 403 means the user is authenticated, but the server won’t allow them to do what they attempted. For example, I log into my bank account and try to view the balance on your bank account. And, finally, a 404 means the thing the user is trying to interact with doesn’t exist. Now, in my bank account example, while a 403 technically makes sense, often the API will return a 404 instead. That’s because a 403 implies that the account exists. If I was an attacker, I just gained information I might be able to use. That’s why checking for some type of failure is often better than checking for a specific type of failure. With that in mind, let’s create two functions. On your own, I’d love to see what you come up with. Let me lay out a simple method for you. We’ll make it protected function iExpectASuccessfulRequest and the other one would be protected function iExpectAFailedARequest. Now, I’ll leave it to you to fill in the details. Come up with a way to catch all the successes or all the errors in each function. Just remember, a simple greater than or less than isn’t going to work because these are ranges, not single integers.
- HTTP Status/Response Codes
- 1xx Informational(uncommon; never used in APIs)
- 2xx Success(common)
- 3xx Redirection
- 4xx Client Errors(common)
- 5xx Server Errors
200 OK. Next, the 201 is used primarily as a result of a post-request when we’ve created something successfully. The 204 is used when we delete something successfully.
- 200 OK
201 Created
204 No Content
The 400s are more complex, but one place where people often get confused is a 401 versus a 403 versus a 404. In normal terms, a 401 means the user is not authenticated. A 403 means the user is authenticated, but the server won’t allow them to do what they attempted. For example, I log into my bank account and try to view the balance on your bank account. And, finally, a 404 means the thing the user is trying to interact with doesn’t exist. Now, in my bank account example, while a 403 technically makes sense, often the API will return a 404 instead. That’s because a 403 implies that the account exists.
- 400 Bad Request
- 401 Unauthorised
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
TechTalk 