What I’ve Been Up to Recently?

Hi there!

As you might know, I haven’t posted anything to TDD Fellow blog for quite a while. I wasn’t just lazy. I have been severely busy.

I was busy creating new things.

Guest Blogging

I’ve written a few guest blog posts, for example this guide might teach you how to make better decisions as a software developer. That article is about stress, willpower, mental health and results in a work of software developer.

Right now I’m writing another guest blog post and talking to more blog authors looking for guest posts.

Reading Complete Software Developer’s Guide

Also, I’ve read an amazing book, best seller in Software Engineering category, that I predict will become one of the classics of Software Engineering, alongside Refactoring and Patterns books - The Complete Software Developer’s Career Guide.

I loved it. It is a book for a software developer of any stage: beginner that is just learning, professional trying to land THAT first job, competent professional software developer itching to improve or an expert software engineer looking for ways to transcend and go beyond a simple software engineering role? Then this book is for you. Read my full review on the Amazon.

Stories on Productivity, Negotiations, and Stress

(for software developers)

I’ve started a whole series of stories and case studies (I call them “War Stories”) on productivity, negotiations, and stress for software developers. So if you want to learn how to negotiate, be productive and handle stress as a software developer, go and grab my stories.

The stories are published under the name of “Productive Developers Only.” One might think: “What a cheesy name!”. I love the name, though. Hehe :) It is not just for Productive Developers Only, it is also for anyone who wants to be more productive, more successful and healthier as a software developer.

So far, I’ve written one case study called “How to Get a Better Offer Accidentally.” It focuses on one simple negotiation technique. In fact, there were already two revisions of that story. And I’ve received some more feedback from my dear friend and colleague Alexis. So I’ll write the third version soon, and it’ll rock! By the way, check out Alexis’ blog: Free is a Verb - it is amazing!

Also, I’m in the process of interviewing a few developers for the next case study called “Why You Need to Work Four Hours Only Per Day.” In fact, you are not working more than four hours per day, even if it takes you eight or more. Isn’t it surprising? If you want to know more, hurry to grab my stories, and you’ll receive the case study as soon as I publish it in a few weeks.

If you are still reading, I’ll throw some more interesting teaser at you ;) How about I tell you what first case study was about?

Julia’s Story

Julia was searching for a first job as a developer after graduating. It was tough, as most companies wanted to hire experienced developers. Julia didn’t lack qualifications for the junior positions. She was interviewing with two startups in her hometown.

Drake’s 24 Hours Challenge or How to Be Less Negative

awareness, emotions, empathy, soft-skills

Did you ever look at the chunk of code that is not very pretty, and immediately uttered some bad word or bad remark, such as “Who wrote this?” And not even noticed it?

Or did you ever had an incident happening in production, and half of your vocabulary at that time was not normative? Also, did you feel stressed and down afterward?

Or did you ever had to converse with a difficult person or someone holding a strong opinion, and thought not very good about them? Or even dismissed a valid argument just because you didn’t like the conversation?

Did you ever felt or did something negative, and thought afterward that it would be better not to? Then the technique described in this article is perfect for you!

Build Your Own Testing Framework. Part 6: Test Suite Does Not Run All Tests!

build-your-own-testing-framework, javascript, tdd, test-driven-development, testing, xunit

Welcome back to the new issue of “Build Your Own Testing Framework” series! When trying to implement better formatting, we have discovered that some of our test suites do not run all tests! Today we are going to fix that, and we will make sure that such test suite will fail if it didn’t execute all tests.

Learning Test-Driven Development With Javascript: End-to-End Testing

javascript, learning-tdd-with-js, tdd, tutorial

Level: Beginner.

“Learning TDD with Javascript” is the series of articles where we learn basics of automated testing and test-driven development. While the language of choice for the code examples is Javascript, all described concepts are language-agnostic and are applicable in various technological stacks. In these articles, a reader is expected to do small exercises after each major topic to reinforce that theoretical knowledge with practice. Some of these exercises are practical and will involve coding, or simple writing; others will be food for thought. Also, a reader might want to get their feedback on these exercises, so don’t hesitate to send the results my way: oleksii@tddfellow.com - feedback on the practice is quite important as it helps to improve quicker, when you know what is well and what can be improved and how. Also, don’t hesitate to send any questions and feedback regarding the content of these articles. Your questions, feedback, and your practical results will help authors shape this content better.

Today we are going to learn how to write tests that imitate real user interaction for the whole application. We are going to build a small web application using Vanilla Javascript. Vanilla Javascript is a plain Javascript without any framework or library. Such tests that imitate real user interaction via User Interface (UI) are called End-to-End Tests. These tests are the most simple to write because we only need to think about our application in the same way user does:

  • Imitating the user clicking on the button would mean for us to trigger a button click;
  • Imitating the user typing text in the input field would mean for us to change input’s value;
  • Imitating the user clicking on the link would mean for us to trigger a link click;
  • And so on.

Mobile Waterfall. Being Agile Again

agile, android, dsl, ios, microservices, mobile, waterfall

Have you ever worked with mobile platforms, such as Apple Store or Google Play? How much time it takes to release a new version of the application? They have ~2-4 days manual review of your mobile application. What do you think that means? - You can release your application to production no often than two times a week. It became much better around this year - before it was 1-1.5 weeks.

waterfall

Understanding Legacy Code Using Explorative Test-Driven Development Technique

legacy-code, ruby, tdd, test-driven-development, testing

Today we are going to learn how to eliminate the fear of changing legacy code. We will learn how to confidently and in small iterations understand the legacy code better while increasing the test coverage in the process. While code examples are in Ruby programming language, the technique applied is language-agnostic.

Build Your Own Testing Framework. Part 5

build-your-own-testing-framework, javascript, tdd, test-driven-development, testing, xunit

Welcome back to the new issue of “Build Your Own Testing Framework” series! Did you notice, that out testing framework quits on the first failure? It probably should run all tests, collect all failures and present them nicely. This is what we are going to accomplish today:

  • Make sure all tests run even when there is a failure.
  • Make sure exit code is correct.