Test Driven Development

What is Test Driven development?

Test driven development is focused on Micro-Activities (Units rather than Functional components) and we can define it as:

“a proven discipline for delivering generic, independent and autonomous components that can be safely used to assemble large, sophisticated systems efficiently”

Test driven development therefore does not include system testing and integration testing strategies as it involves Unit Testing which is prefered due to its simplicity meaning that it is easy to simulate and measure. Unit Testing is enabled by the absence of dependencies.

Writing quality tests

There are various principles for writing well structured unit test code,we will begin with FIRST principles:

  • F – Fast
  • I – Independent
  • R – Repeatable
  • S – Self Validating
  • T – Thorough


Unit tests should be very fast to run since they expect simple processing from the implemented code


Unit tests should be simple to prrocess and does not depend on other unit tests


Unit Tests should produce same result as the previous time it ran.


The outcome of result should be instantly visible to the programmer


Unit tests should describe all the expectations as defined in the micro-examples

producing well-structured unit tests that fulfill the FIRST principles, does not guarantee that we have delivered a solid solution.

Methodology for writing reliable and quality code is based on clean code SOLID Principle

  • S – Single Responsibility Principle
  • O – Open-Closed Principle
  • L – Liskov Substitution
  • I – Interface Segregation Principle
  • D – Dependency Inversion Principle

Single Responsibility Principle

Each unit test must have one and only one Assert statement. This means that each component must be responsible for performing only one operation

Open-Closed Principle

This principle states that a component should be open for extensions but closed for modification. Applied to unit tests it ensures that we will not implement a change to an existing unit test in that unit test. Instead we must write a brand new unit test that will implement the changes.

Liskov Substitution Principle

This principle provides a guide for deciding which level of abstraction may be appropriate for the solution.“If it looks like a duck and quacks like a duck but needs batteries, you probably have the wrong abstraction”

Interface Segregation Principle

Reminds us not to bloat APIs
When subsystems need to collaborate to complete a task, they should communicate through interface. If new capability becomes necessary don’t add it to the already defined interface; instead, craft a brand new interface.

Applied to unit tests, removing the bloat from the interfaces helps us craft more specific unit tests which in turn, results in more generic components.

Dependency Inversion Principle

We should control our dependencies instead of dependencies controlling us.If there is need to use another component’s services instead of being responsible for instantiating that component within the component we are building. It must be injected to our components.
Applied to unit tests, this principle helps separate the intention from the implementation. We must strive to inject only those dependencies that have been sufficiently abstracted. This approach is important in ensuring unit tests are not mixed with integration tests.


What is design thinking?

#question mark

According to David Kelley design thinking is described as human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.’ In a nutshell, design thinking is basically ‘a human-centered approach to solving problems using the designer’s toolkit’.

Why is design thinking important?

#problem solving
#quick maths
#problem solver
#funny math problem
#math 101

It’s the key to solve most if not all of problems as it creates a breeding ground for empathy. Which makes It easy to recognize  products that consumers need and those that they don’t.

The Design thinking process

  1. Empathize — with users
  2. Define — users’ needs, their problem, and your insights
  3. Ideate — challenge assumptions and produce ideas for innovative solutions
  4. Prototype — begin creating solutions
  5. Test — solutions

How to build better products using design thinking?

  1. Stop copy pasting innovations that work in other countries.
  2. Think more of coming up with the solution rather than fixating on the challenge.
  3. Empathy! Empathy! Empathy!
  4. Make the people you are solving the problem for feel as if their part of the solution

Enabling Auto-save on Sublime-Text IDE

While it may not seem like a big deal to keep pressing Ctrl+S its easier and time saving to enable auto-save in your IDE. For users of Sublime text the auto-save option is not included on the visual interface, you have to enable it manually on the settings code.

Now to enable auto-save follow these simple steps and you will be set.

  1. Open Sublime-text
  2. Once Sublime is open, on the top bar navigate to Preferences —> settings. A new window will be opened with two columns. On one column you will see Default-Settings on the other you will find User-settings.
  3. On the User-settings on the right edit them and add the following line
    { "save_on_focus_lost": true }
  4. Save the settings and exit. Now once you edit any file you can see at the bottom panel its auto-saved automatically.

Linux Shell

Shell Environments

Linux shell is made up of components that can be customized to the user’s preference using:

  • VARIABLES: The most commonly customized part of the shell.
  • FUNCTIONS: Defines the core functionalities of the shell
  • ALIASES: Shortcuts

Shell Variables and settings

Global Profiles (All Users)

When invoked interactively with the –login option or when invoked as sh, Bash reads the /etc/profile instructions.


  • /etc/profile.d/*.sh
  • the /etc/profile.d directory, which contains files configuring system-wide behavior of specific programs.
  • /etc/profile.local

etc/bashrc contains system-wide definitions for shell functions and aliases.


  • /etc/bash_completion.d/*.sh
  • /etc/bash.bashrc.local

These files might not be in your home directory by default; create them if needed.

User specific profiles

  • ~/.profile
  • ~/.bashrc
  • ~/.alias