Julio Biason
6 years ago
6 changed files with 102 additions and 3 deletions
@ -0,0 +1,42 @@ |
|||||||
|
+++ |
||||||
|
title = "Things I Learnt The Hard Way - Disclaimer" |
||||||
|
date = 2019-06-19 |
||||||
|
|
||||||
|
[taxonomies] |
||||||
|
tags = ["en-au", "books", "things i learnt", "disclaimer"] |
||||||
|
+++ |
||||||
|
|
||||||
|
There is one magical thing you need to know when reading this book: It's all |
||||||
|
personal opinion |
||||||
|
|
||||||
|
<!-- more --> |
||||||
|
|
||||||
|
A lot of stuff I'm going to discuss throughout this book will come directly |
||||||
|
from my personal experience in several projects -- system applications, web |
||||||
|
backend, embedded, mobile, stream processing -- in several different languages |
||||||
|
-- C, C++, Python, Java. And, because it comes from personal experience, |
||||||
|
everything reflects my own personal opinion on several subjects. |
||||||
|
|
||||||
|
Obviously, you don't need to agree with every single point. |
||||||
|
|
||||||
|
Also, sometimes I may mention some examples that people who know me -- either |
||||||
|
worked with me, heard me complain about some project, inherit one of my |
||||||
|
projects, _I_ inherit one of the _their_ projects -- may recognized and think |
||||||
|
I'm attacking the author. |
||||||
|
|
||||||
|
I am not. |
||||||
|
|
||||||
|
We do mistakes. Sometimes we don't know the topic with are attacking, |
||||||
|
sometimes we don't have full specs, sometimes we don't have the time to write |
||||||
|
things properly in a crunchtime. And that's why some things don't look as |
||||||
|
pretty as they should. Heck, if you think I'm attacking the original author of |
||||||
|
some example, look back the stuff I wrote and you'll see things a lot worse. |
||||||
|
|
||||||
|
But I need the example. I want to show people how things can be better. I want |
||||||
|
to show people how my opinion built over some subject. And, again, I'm in no |
||||||
|
way attacking the original author of the code. I may even call the code |
||||||
|
"stupid", but I'm not calling the author _stupid_. |
||||||
|
|
||||||
|
With that in mind... |
||||||
|
|
||||||
|
{{ chapters(prev_chapter_link="/books/things-i-learnt/intro", prev_chapter_title = "Intro", next_chapter_link="/books/things-i-learnt/spec-first", next_chapter_title="Spec First, The Code") }} |
@ -0,0 +1,54 @@ |
|||||||
|
+++ |
||||||
|
title = "Things I Learnt The Hard Way - Gherkin Is Your Friend to Understand Expectations" |
||||||
|
date = 2019-06-19 |
||||||
|
|
||||||
|
[taxonomies] |
||||||
|
tags = ["en-au", "book", "things i learnt", "gherkin", "expectations"] |
||||||
|
+++ |
||||||
|
|
||||||
|
Gherkin is file format for writing behaviour tests. But it can also give you |
||||||
|
some insights on what you should do. |
||||||
|
|
||||||
|
<!-- more --> |
||||||
|
|
||||||
|
Alright, let's talk a bit about Gherkin: |
||||||
|
|
||||||
|
[Gherkin](https://en.wikipedia.org/wiki/Cucumber_(software)#Gherkin_language) |
||||||
|
is a file format created for [Cucumber](https://en.wikipedia.org/wiki/Cucumber_(software)), |
||||||
|
which describes scenarios, what's in them, what actions the user/system will |
||||||
|
do and what's expected after those actions, in a very high level, so people |
||||||
|
without programming experience can describe what's expected from the system. |
||||||
|
|
||||||
|
Although Gherkin was born with Cucumber, it is now supported by a bunch of |
||||||
|
programming languages, through external libraries. |
||||||
|
|
||||||
|
A typical Gherkin file may look something like this: |
||||||
|
|
||||||
|
* **Given that** _initial system environment_ |
||||||
|
* **When** _action performed by the user or some external system_ |
||||||
|
* **Then** _expected system environment_ |
||||||
|
|
||||||
|
Or, in a more concrete example: |
||||||
|
|
||||||
|
* **Given that** The system is retrieving all tweets favourited by the user |
||||||
|
* **When** It finds a tweet with an attachment |
||||||
|
* **Then** The attachment should be saved along the tweet text |
||||||
|
|
||||||
|
Pretty simple, right? |
||||||
|
|
||||||
|
Now, why I'm mentioning this? |
||||||
|
|
||||||
|
Sometimes, specs are not the most clear source of information about what it is |
||||||
|
expected from the system. If you're confused about what you should write, |
||||||
|
asking the person responsible for the request to write something like Gherkin |
||||||
|
may give you some better insights about it. |
||||||
|
|
||||||
|
Obviously, it won't be complete. People tend to forget the error situations -- |
||||||
|
people entering just numbers on names, letter in age fields, tweets with no |
||||||
|
text and just attachments -- but at least with a Gherkin description of the |
||||||
|
system, you can get a better picture of the whole. |
||||||
|
|
||||||
|
Also, you may not like to write specs. That's alright, you can replace them |
||||||
|
with Gherkin anyway. |
||||||
|
|
||||||
|
{{ chapters(prev_chapter_link="/books/things-i-learnt/steps-as-comments", prev_chapter_title="Write Steps as Comments") }} |
Loading…
Reference in new issue