(This blog was written by Benjamin Bischoff)
Writing a book is a daunting task, especially when it’s about a technical topic like API testing with Karate. This is my journey from the first empty page to the finished book which officially launched today!
What? A book?
I never seriously thought about writing a book. During my career, I had written quite some blog posts and two magazine articles but never something too extensive and in-depth. So it came quite as a surprise when I was approached by Packt Publishing to talk about a potential project.
Unfortunately, I was not the right person for what they had in mind. I won’t disclose the initial topic here. Let’s just say that I didn’t have enough knowledge or practice with this subject. I turned this down but took the chance to pitch something else that I was actively working with and had experience in: writing a book on Karate API testing.
This was a rather spontaneous idea, because we have been using this testing framework in our company for some time and I gradually gained more and more knowledge about it. Also, I noticed that there was no literature about it yet, only the official online documentation, a lot of Stack Overflow posts and occasional Tweets showcasing some functionality.
It’s getting more serious.
The first step for me was to fill out a document detailing the concept of the book, its chapters, key learnings and potential audience. Based on this document, Packt started researching about the Karate framework, its distribution and the state of literature around it. When they came back with their findings, it took some more video calls to finalise the contract, some more conversation with HR to get the necessary permission for a sideline activity and, of course, to my family. After all, they would have to deal with me not being available for quite a while.
The toughest part about this initial document was the estimation of the needed number of pages for each chapter. What I later found out was that this number is not just an arbitrary placeholder but it is expected that the chapters roughly adhere to these numbers. This is also called out by reviewers and if there is a larger deviation from it, you need to be prepared to explain why this is. You are always free to make changes to the structure of the book if you have good reasons for it. This happened multiple times throughout the writing process as the overarching theme, tone and breakdown of the book becomes clearer.
Procrastination vs Deadlines
I am a procrastinator. When I tell people this, often times they are quite surprised since I usually get stuff done. The thing is that this often times happens at the last second. This is why the contract I finally received from Packt looked very scary at first as there were very tight deadlines set for every phase of the writing process. For each chapter, there is a clear date for the deliverables, when the different reviews are done and when the revised and corrected chapters have to be returned.
This helped a lot! Having these close dates always in front of my eyes helped me focus and that’s what drove me to write on.
Packt suggested a writing schedule of about one to two hours per day. I tried but this was not for me. Some days I wrote absolutely nothing whereas on other days, I was “in the flow” and worked for four to six hours until the night.
Gradual improvement
The first chapter was a huge struggle. Fortunately, the Packt staff (Rounak Kulkarni, Kunal Sawant and Deeksha Thakkar) was always there for any questions, concerns and doubts. Also, I have to say that the quality of the reviews was really good and improved clarity and understandability for the readers a lot. You can tell that all of them have a lot of experience working together with a lot of authors and handling the whole process as smoothly as possible.
Also, I was lucky that Saurav Sharma, who works with me at trivago, agreed to be my technical reviewer. Having him close by helped immensely eliminating mistakes in my example code, clarifying steps and even finding solutions for problems with certain operating systems or setups. His role was also crucial to keep this book correct.
Writing got a little hectic whenever previous chapters came back for revision, even though I was already in the middle of the next one. This change of focus was not so easy, but eventually helped to align the chapters more and more. It also makes for a better workflow, as you can finish chapters faster. It would have been much worse to have to revise all the chapters again in one package after writing the entire book!
Writing is the easier part
Also, it must be said that writing was not necessarily the biggest part of the project. Depending on the chapter, a lot of research in dozens of sources, trial and error, overcoming frustration when something didn’t work right, writing and improving sample code, taking screenshots, maintaining the GitHub repository that comes with the book, etc. was needed.
I found that when I spend a lot (and I mean a lot) of time on good example code first, writing about this became much easier than coming up with the text and example code at the same time. This gave me a good basis and guideline for clear explanations.
Conclusion
“Writing API tests with Karate” has been a journey where I have learned a lot about writing, testing, persevering and last but not least myself. It was an incredible experience, and I’m grateful for the opportunity to share my knowledge with others through this book.
I would also like to thank my wife Anne and my daughter Frida once again. I couldn’t have done it without their support and the space they gave me!
If you are now interested in learning more about the book, you can find more information here.
If that has already piqued your interest, you are also welcome to order it directly on Amazon or other major book vendors.
I look forward to your feedback and hope you enjoy reading the book at least as much as I enjoyed writing it!
