DEV Community: Malcolm R. Kente

5 Lessons from the Leap: From Developer to Engineering Manager

Malcolm R. Kente — Mon, 05 May 2025 15:11:50 +0000

So, you're thinking of moving from developer into a management role? Or maybe you've already made the jump and now wondering why didn't anyone warn me that my days will be filled with meetings, feedback, and a never-ending Slack/Email inbox?

Well... I've been there.

I started as a developer, stepped into a tech lead role (aka wearing many hats- scoping requirements, estimating and delegating tasks, mentoring, occasional therapist), and eventually made the move into engineering management. And let me tell you, it's not just a title change. It's a total shift in how you define success, spend your time, and (perhaps most challenging) - how you cope with not shipping code every day.

If you’re thinking about making the move (or still getting used to it), here are some hard-earned lessons that I wish someone had shared with me earlier.

1️⃣ Being a Good Developer Won't Make You a Good Manager

As a developer, your success is about what you build. You write great code, solve hard problems, and maybe even win a few debates over semicolons. But as a manager, your success is measured differently: It's not about what you do, but what your team(s) accomplishes.

Instead of debugging code, you're debugging people and processes. Instead of making every technical decision, you're guiding others to make them. And instead of focusing on your output, your focus becomes removing roadblocks so your team(s) can do their best work.

It's no longer about "Look what I built", it's about "Look what my team(s) built".

🌟 Takeaway - If you measure your worth by how much you ship, you’ll struggle as a manager. Your new job is about unlocking your team’s potential... not being the smartest coder in the room!

2️⃣ Your Technical Skills Still Matter, Just in a Different Way

You won't be coding full-time anymore... and that's okay! Your tech skills won't go to waste, they take on a new supporting role. Now you use them to:

Guide architectural discussions without making every decision yourself.
Mentor team members instead of fixing their code.
Advocate for smart technical investments in leadership meetings.

The challenge is staying technical enough to be helpful and informed, without becoming the bottleneck. For me, that’s meant asking better questions, keeping a pulse on key decisions, and letting lead/senior engineers take the lead on deep technical work.

🌟 Takeaway - Be the person who helps others do their best work. And then step back so they can do it.

3️⃣ People Are Harder Than Code (And That's a Good Thing)

You thought debugging a multi-threaded race condition was tough? Try giving feedback to a struggling team member without crushing their spirit.

Management is a mix of people problems, process tuning, and occasionally explaining to leadership why things take time. The toughest challenges I’ve faced haven’t been technical, they’ve been human:

Navigating conflicts between team members with wildly different working styles.
Figuring out how to give constructive feedback without sounding like a jerk.
Convincing leadership that something like hiring and/or onboarding should have enough iterations and time in order to reap the best benefits.

The trick here is learning to debug people and processes instead of just code. This means listening more than you speak, because sometimes people don't need a solution, they just need to be heard. It means being direct, but kind. Giving feedback that is honest, specific, and actionable. And most importantly, it means protecting your team! Shielding them from unnecessary chaos while keeping them informed and engaged.

🌟 Takeaway - Leading well means understanding, motivating, and supporting your team. Just as much as (if not more than) understanding your tech stack.

4️⃣ Feedback & Communication Are Your Most Important Tools

No, seriously. If you don’t communicate clearly and regularly, your team(s) will drift into chaos.

One of the biggest mindset shifts for me was realizing that feedback works best when it’s frequent and light, not just saved for formal reviews. Real-time, actionable feedback creates momentum.

Regular 1:1s that go beyond status updates. Real conversations about goals, blockers, and growth
Reinforcing the good stuff, not just pointing out problems
Encouraging peer feedback so improvement becomes a shared responsibility

🌟 Takeaway - The best teams talk a lot! About what’s working, what’s not, and how they’re improving together.

5️⃣ Managing Up & Across is Just as Important as Managing Your Team

Eventually, you realize that supporting your team isn’t enough. You also have to navigate the environment around them. Your team’s success depends on how well you manage relationships with leadership, product, design, and beyond.

That means translating technical challenges into business terms that leadership actually understands (and cares about). Pushing back on unrealistic timelines without sounding like you’re just making excuses. All the while building trust with other teams.

Because the truth is good engineering doesn’t happen in a vacuum. It happens when the entire organization is aligned and rowing in the same direction.

🌟 Takeaway - Want your team to succeed? Make sure other teams, stakeholders, and leadership understand their goals (& you to have their back).

Final Thoughts - The Best Managers are Multipliers

Making the move from Developer or Tech Lead to Engineering Manager was a full-on mindset shift for me. I had to stop measuring my success by what I personally built, and start looking at what my team accomplished. That wasn’t always easy, but it’s where the real impact lives.

If you’re stepping into this role, here’s what I’d share from my own experience:

Embrace the shift! Your job really becomes more about people, processes, and strategy than perfecting pull requests.
Stay technical, but learn to let go of control. Your team(s) need space to lead, grow, and yes, sometimes stumble.
Learn to coach, not just direct. Mentorship beats micromanagement every time.
Feedback is your most powerful tool. Give it often. Ask for it even more. Use it to build trust and momentum.
Managing up & across is just as important as managing down.

The most rewarding part? Realizing that your best work is no longer what you personally ship... it’s what you empower others to build. 🚀

Scrolling Text Animation With Funky Borders

Malcolm R. Kente — Fri, 02 Apr 2021 15:14:05 +0000

This will be a quick one for simple animation lovers 🥰

The following code covers creating scrolling text which moves across the screen. Additionally, I'll add a funky border to the scrolling text.

For the love of A Tribe Called Quest, the chosen colors & font pay homage to The Low-End Theory album. Enjoy Buggin Out to this as I did.

-- 1️⃣ --

We'll import our font choice and set up the color palette in the root. We use CSS variables to pass on data to pass on these properties later on in the code.

@import url('https://fonts.googleapis.com/css2?family=Permanent+Marker&display=swap');

:root {
  --green: #2e9d1e;
  --red: #fc040c;
  --black: #181816;
  --white: #e9eef4;
  --font: "Permanent Marker"; 
}

-- 2️⃣ --

To keep this simple, we'll be giving the following h1 the ability to scroll across the page.

<div class="scrolling-container">
  <h1><span>Scrolling Text</span></h1>
</div>

A div with the class of scrolling-container wraps around the h1. The scrolling container will hold the following properties:

.scrolling-container {
  position: relative;
  width: 100%;
  overflow-x: hidden;
  overflow-y: hidden;
}

👉 position: relative; ensures the div remains "in the flow" of the layout but still movable!
👉 width: 100%; gives the div the ability to take up its full width
👉 both overflow-x: hidden; and overflow-y: hidden; make it so that the div has no scrolling mechanism within itself.

-- 3️⃣ --

Now for our h1, we give it the following properties.

h1 {
  font-family: var(--font);
  letter-spacing: 3px;
  line-height: 50px;
  text-transform: uppercase;
  padding: 15px;
  font-size: 3em;
  color: var(--white);
  text-align: center;
  transform: translateX(100%);
  animation: scrolling-text 10s linear infinite;
}

👉 The font-family and color properties use CSS variables to access the color and font we defined in the root.
👉 transform: translateX(100%) repositions the element in a vertical direction.
👉 animation: scrolling-text 10s linear infinite; sets the scrolling animation to this h1 element. scrolling-text is the name of the animation made by keyframes below.

-- 4️⃣ --

We'll give our text some "Low-End" styling by targeting the span element.

span {
  background-color: var(--black);
  box-shadow: 0.2em 0.2em 0 0 var(--red), inset 0.2em 0.2em 0 0 var(--green);
}

So our funky border is in actuality a box-shadow. The box-shadow property combines an outset (outer shadow) with an inset (inner shadow)

-- 5️⃣ --

Finally, the @keyframes properties that help create our scrolling animation take control of the transform:translateX property of our h1 element.

@keyframes scrolling-text {
  0% {
    transform: translateX(100%);
  }
  100% {
    transform: translateX(-100%);
  }
}

The main thing here is our element's state when it starts (at 0%) to when it ends (at 100%). Setting it from 100% to -100% will move the element from the right side of the screen to the left.

Just like that, we have some scrolling text with some funky borders. I hope you enjoyed this Scenario... I had fun making it ✌️

You can find the full code snippet here

Usage can be seen here

Nesting Template Literals: A Recommended Approach

Malcolm R. Kente — Thu, 18 Mar 2021 15:59:46 +0000

Code quality is essential, as it impacts the overall software quality. In consequence, software quality affects the safety, security, and reliability of any codebase.

The backstory 🔙

For a few months now, I'm using SonarCloud on my GitHub repositories to monitor code quality. I find it a valuable tool for checking my code and keeping me updated on any corrections needed. Additionally, I've also learned a great deal about coding practices that I would typically neglect.

One of the "code smells" picked up was the nesting of Template Literals. SonarCloud gave me a big fat notice saying Template literals should not be nested

My Problem 🤔

This issue resulted from my attempt to add breakpoints to my styled-components on a project. The problem turned out to be a good learning moment. Thus, here is me sharing the lesson with you to hopefully not repeat my mistakes.

Nesting together multiple template literals can create unnecessary complexity, which reduces the code quality. The code becomes less readable and can cause maintainability issues overtime.

Consider this example:

let color = "red";
let count = 3;
let message = `I have ${color ? `${count} ${color}` : count} apples`; // Noncompliant; nested template strings not easy to read

A better practice, in these situations, is to move the nested template into a separate statement.

let color = "red";
let count = 3;
let apples = color ? `${count} ${color}` : count;
let message = `I have ${apples} apples`;

Here is the initial setup of my styled-components file. It is the hero section of an application. Within the styled section, respondToDeviceWidth creates a nested template literal with CSS values.

// HeroStyles.js

import styled from 'styled-components';
import respondToDeviceWidth from '../../utils/mediaQueries';

export const StyledHeroSection = styled.section`
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
  background: linear-gradient(
    145deg,
    rgba(253, 38, 71, 1) 0%,
    rgba(252, 128, 45, 1) 75%,
    rgba(250, 167, 43, 1) 100%
  );

  ${respondToDeviceWidth.sm`
    margin-bottom: 2em;
  `}
`;

respondToDeviceWidth utilizes styled-components css prop to create the required media query depending on the chosen breakpointsData.

// utils/mediaQueries/index.js

import { css } from 'styled-components';
import breakpointsData from '../../data/breakpointsData';

const respondToDeviceWidth = Object.keys(breakpointsData).reduce(
  (acc, label) => {
    acc[label] = (...args) => css`
      @media (min-width: ${breakpointsData[label]}) {
        ${css(...args)};
      }
    `;
    return acc;
  },
  {}
);

export default respondToDeviceWidth;

breakpointsData is an object which holds some standard device widths.

// data/breakPointsData.js
const breakpointsData = {
  xs: '480px',
  sm: '768px',
  md: '992px',
  lg: '1200px',
};

export default breakpointsData;

The Solution 💡

The main issue pointed out by SonarCloud to me was the nesting of the template literals in my styled hero component. To fix this, all I needed to extract the respondToDevice width into a separate statement.

// HeroStyles.js

import styled from 'styled-components';
import respondToDeviceWidth from '../../utils/mediaQueries';

const smStyles = respondToDeviceWidth.sm`
margin-bottom: 2em;
`;

export const StyledHeroSection = styled.section`
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
  background: linear-gradient(
    145deg,
    rgba(253, 38, 71, 1) 0%,
    rgba(252, 128, 45, 1) 75%,
    rgba(250, 167, 43, 1) 100%
  );

  ${smStyles}
`;

Conclusion 🏁

That's pretty much it. I learned a better method for nesting template literals. A method that reduces the complexity of my codebase. Thanks to SonarCloud, I was to improve my code quality (by a small significance atleast).

Now are SonarCloud recommendations and practices the only ones that set in stone? Most likely not! As far as code analyzers go, I'm sure there are a plethora of choices.

Let me know more about them in the comments below ✌️

Full repo 👉 here 👈

Testing with MongoDB-Memory-Server

Malcolm R. Kente — Tue, 16 Feb 2021 13:30:36 +0000

I've recently been taking a deeper dive into testing. I am taking the time to create projects that have reasonable code confidence. Over time the goal is to create and deploy applications that are adequately tested and have decent code coverage.

One of the things I found is that testing the database is not always straightforward. Here is an overview of how I did just that on one of my projects.

Backstory 🔙

The project I am working on is called OnLearn. It is essentially a POC for an e-Learning Management System. It will function as a platform where potential users can either put up courses or take courses. Quite similar to Udemy, SkillShare, or any of the MOOC platforms out there, actually.

The application's stack is Node.js, MongoDB (Mongoose ODM), and uses Handlebars for the view. Jest is the testing framework used.

Problem 🤔

One of the first challenges that presented itself was the testing of MongoDB. I wanted to be able to write unit tests for the database logic without relying heavily on mocks.

After looking into different solutions, I came across two articles that looked at testing mongodb using an in-memory database:

☝️ In-memory MongoDB for Testing.
✌️ Testing Node.js + Mongoose by Paula Santamaría

In both articles, the authors refer to nodkz's mongodb-memory-server package.

What is mongodb-memory-server?
It is a package that spins up a real MongoDB server. It enables us to start a mongod process that stores data in memory.

In-memory databases are spun up, ran, and closed in the application's main memory itself. Making them fast as they never touch the hard-drive, and are fit for testing as they are destroyed instantly upon closing.

The Solution 💡

Here is how mongodb-memory-server helped me write unit tests for one of the OnLearn application's models:

1️⃣ Install dependencies.
2️⃣ Configure Jest.
3️⃣ Setup in-memory database.
4️⃣ Create a model.
5️⃣ Write unit tests.

1️⃣ Install dependencies.

The following commands will install jest and mongodb-memory-server simultaneously.

npm i jest mongodb-memory-server

2️⃣ Configure Jest.

👉 Test Script
Add a test script to the package.json with the following commands.

"scripts": {
    "test": "jest --runInBand --detectOpenHandles",
}

CLI Options Overview

"test" - refers to the script name for running the tests.
jest - the default command to run all tests.
--runInBand - the command that runs all tests serially in the current process, rather than creating a worker pool of child processes that run tests.
--detectOpenHandles - the command that will attempt to collect and print open handles that prevent Jest from exiting cleanly.

👉 Test Environment
The default environment in Jest is a browser-like environment via jsdom. For node applications, a node-like environment should be specified instead.

"jest": {
    "testEnvironment": "node",
}

3️⃣ Setup in-memory database.

A separate file sets up the mongodb-memory-server with functions that will connect and disconnect.

// utils/test-utils/dbHandler.utils.js

const mongoose = require('mongoose');
const { MongoMemoryServer } = require('mongodb-memory-server');

const mongoServer = new MongoMemoryServer();

exports.dbConnect = async () => {
  const uri = await mongoServer.getUri();

  const mongooseOpts = {
    useNewUrlParser: true,
    useCreateIndex: true,
    useUnifiedTopology: true,
    useFindAndModify: false,
  };

  await mongoose.connect(uri, mongooseOpts);
};

exports.dbDisconnect = async () => {
  await mongoose.connection.dropDatabase();
  await mongoose.connection.close();
  await mongoServer.stop();
};

A closer look at what is happening:

Import mongoose and mongodb-memory-server.


 const mongoose = require('mongoose');
 const { MongoMemoryServer } = require('mongodb-memory-> server');

New mongodb-memory-server instance that will be used to run operations on in-memory db.


 const mongoServer = new MongoMemoryServer();

A function to connect the in-memory database.


 exports.dbConnect = async () => {
   const uri = await mongoServer.getUri();

   const mongooseOpts = {
     useNewUrlParser: true,
     useCreateIndex: true,
     useUnifiedTopology: true,
     useFindAndModify: false,
   };

   await mongoose.connect(uri, mongooseOpts);
 };

A function to disconnect the in-memory database.


 exports.dbDisconnect = async () => {
   await mongoose.connection.dropDatabase();
   await mongoose.connection.close();
   await mongoServer.stop();
 };

4️⃣ Create a model.

Here is the User model from the application.

Users are verified using Passport local & google strategies.
Thus, the user schema includes:

local and google fields for authentication data.
profilePictureUrl for the user's avatar.
role for the type of user.

// database/models/user.model.js

const { Schema, model } = require('mongoose');

const userSchema = new Schema({
  local: {
    firstName: {
      type: String,
      trim: true,
    },
    lastName: {
      type: String,
      trim: true,
    },
    username: {
      type: String,
      trim: true,
      unique: true,
    },
    email: {
      type: String,
      match: [/^\S+@\S+\.\S+$/, 'Please use a valid email address.'],
      unique: true,
      lowercase: true,
      trim: true,
    },
    password: { type: String },
  },
  google: {
    id: String,
    token: String,
    email: String,
    name: String,
  },
  profilePictureUrl: {
    type: 'String',
    default: 'https://via.placeholder.com/150',
  },
  role: {
    type: String,
    enum: ['student', 'instructor', 'admin'],
    default: 'student',
  },
});

module.exports = model('User', userSchema);

5️⃣ Write unit tests.

Finally, use the created operations to create a connection with mongo-memory-server for the unit tests.

Here's an example of how the user model was tested in the application. Fixtures and assertions are placed in separate modules ...

👉 Fixtures

// database/fixtures/index.js

exports.fakeUserData = {
  firstName: 'Dummy',
  lastName: 'User',
  username: 'dummyUser',
  email: 'dummy@user.com',
  password: '********',
  role: 'student',
};

👉 Test Assertions Helpers

// utils/test-utils/validators.utils.js

exports.validateNotEmpty = (received) => {
  expect(received).not.toBeNull();
  expect(received).not.toBeUndefined();
  expect(received).toBeTruthy();
};

...

exports.validateStringEquality = (received, expected) => {
  expect(received).not.toEqual('dummydfasfsdfsdfasdsd');
  expect(received).toEqual(expected);
};

...

exports.validateMongoDuplicationError = (name, code) => {
  expect(name).not.toEqual(/dummy/i);
  expect(name).toEqual('MongoError');
  expect(code).not.toBe(255);
  expect(code).toBe(11000);
};

Finally, the fixtures, assertion helpers, and db operations are used in the test. 🥳🥳🥳

👉 User Model Unit Test

const User = require('../user.model');
const { fakeUserData } = require('../../fixtures');
const {
  validateNotEmpty,
  validateStringEquality,
  validateMongoDuplicationError,
} = require('../../../utils/test-utils/validators.utils');
const {
  dbConnect,
  dbDisconnect,
} = require('../../../utils/test-utils/dbHandler.utils');

beforeAll(async () => dbConnect());
afterAll(async () => dbDisconnect());

describe('User Model Test Suite', () => {
  test('should validate saving a new student user successfully', async () => {
    const validStudentUser = new User({
      local: fakeUserData,
      role: fakeUserData.role,
    });
    const savedStudentUser = await validStudentUser.save();

    validateNotEmpty(savedStudentUser);

    validateStringEquality(savedStudentUser.role, fakeUserData.role);
    validateStringEquality(savedStudentUser.local.email, fakeUserData.email);
    validateStringEquality(
      savedStudentUser.local.username,
      fakeUserData.username
    );
    validateStringEquality(
      savedStudentUser.local.password,
      fakeUserData.password
    );
    validateStringEquality(
      savedStudentUser.local.firstName,
      fakeUserData.firstName
    );
    validateStringEquality(
      savedStudentUser.local.lastName,
      fakeUserData.lastName
    );
  });

  test('should validate MongoError duplicate error with code 11000', async () => {
    expect.assertions(4);
    const validStudentUser = new User({
      local: fakeUserData,
      role: fakeUserData.role,
    });

    try {
      await validStudentUser.save();
    } catch (error) {
      const { name, code } = error;
      validateMongoDuplicationError(name, code);
    }
  });
});

Passing tests

You can find all tests and implementations here

Conclusion 🏁

In the end, the mongodb-memory-server package did a lot of database heavy lifting for my tests. I use the dbConnect and dbDisconnect operations and test the models for my application and even the services associated with those models.

Let me know what you think about this?
And feel free to share any improvement tips for this. ✌️

Find the mongodb-memory-server repository 👉 here 👈
Find the OnLearn repo 👉 here👈

First Impressions & Conversion Rates

Malcolm R. Kente — Tue, 26 Jan 2021 11:08:38 +0000

For The Reader 📰

A lot of time has been spent lately to gain a better understanding of web design and its' principles. As a full-stack developer, I feel there is good reason to knowing the full spectrum that goes into software development and creating full-stack applications.

The following article focuses mainly on First Impressions and Conversion Rates. Specifically, it introduces these concepts and paints a picture of why they're essential to know.

At the end of this article, I share 🖐️ things that can be beneficial for devs (or anyone interested really) to know. Applied well, these things aid in creating lasting First Impressions and may boost Conversion Rates.

🚫 I want to be very clear that this isn't a "Miracle-Solution". 🚫

Rather, take these 5 things as starting points and feel free to dig up some more things that help.

The Actual Article: Introduction 🚀

"You never get a second chance to make a first impression" - author undetermined

There is still no clear accreditation for who initially said the quote above. Some say Will Rogers said it, some say, Oscar Wilde, I've even heard Head & Shoulder's get credit for it.

Regardless, the fact is that this quote remains true in our current day. Forming an impression from an initial encounter is immediate for most people. Lasting judgments happen within the blink of an eye. 👀

It takes the average person about 0.1 seconds (100 milliseconds) to form an impression about someone. It is a natural ability we have developed over time - a means for humans to survive and thrive through our evolutionary journey.

Our ability to judge trustworthiness in others has evolved as an essential survival mechanism. Natural selection displaces any capacity that isn't beneficial to our survival. Our current capabilities are evidence of that. As a result of our evolution, one of our skills is the ability to make fast decisions and snap judgments.

With our evolutionary capabilities in mind, it is then impressive how quick we are to form impressions.

😲 0.1 seconds is a remarkably fast amount of time!

On the other hand, life has also proven that a lot can happen in that timeframe. Consider this:

👉 A hummingbird can flap its wings eight times in 0.1 seconds.
👉 The earth moves about 46 meters in 0.1 seconds.
👉 Portland Trailblazer's point guard, Damian Lillard, hit a game-winning 3-pointer over the Houston Rockets in 2014, advancing his team to the western conference semi-finals in 0.1 seconds.

Photo by Skitterphoto from Pexels

You see, a lot can happen in 0.1 seconds. It is then not surprising we can form an impression in that short amount of time. It is a fact unavoidable in our daily lives. This fact is equally inevitable when dealing with websites.

First Impressions on Web Applications/Sites 🤩

The first sight a user gets on an application or site can have a lasting effect on their future interactions. A user's initial reaction is similar to that of a real-life encounter. It is quick and lasts for a long time.

In some cases, it is even quicker to form impressions of web applications or sites than that of real-life encounters.

It takes about 50 milliseconds (0.05 seconds) for users to form an opinion about a website. An impression that determines whether they stay or leave. In other words, whether our applications or sites have a chance to increase the conversion rate or not.

What are Conversion Rates? 📈

An application's or site's conversions are what happens when a user takes a desired action. It may include things like:

👉 Signing up for a newsletter
👉 Filling out a form
👉 Clicking a button
👉 Making a purchase
👉 Sharing blog posts on social media

A percentage of users that complete the desired action is known as the Conversion Rate.

It is essential to generate conversions. Generated conversions mean that whatever desired action intended for a user, was taken. The conversion rate will represent the number of users who took action.

🖐️ Tips To Help Create Lasting Impressions While Increasing The Conversion Rate

Photo by Miguel Á. Padriñán from Pexels

Many things can increase and improve conversion rates. Here are 5 in which you can start with:

1️⃣ Invest in quality design for your website.
2️⃣ Optimize website speed.
3️⃣ Have clear and visible calls-to-action (CTAs) that will prompt a user to take action.
4️⃣ Establish legitimacy by providing credible trust indicators (testimonials, case studies, etc.)
5️⃣ Ensure responsiveness on your website.

Conclusion 🏁

Good design implemented well makes it easier to make the best possible first impression. The look an application or a site has and the user experience are the primary drivers of first impressions.

Excellent user experience encourages long-lasting First Impressions. Memorable first impressions positively affect users when browsing. Happy and satisfied users are sure to increase the Conversion Rate.

If you've enjoyed the article, bookmark it and share it with anyone else who may benefit from this.

Feel free to share any thoughts, tips, suggestions in the discussion section below 👇

Helper Functions for Assertions (Jest & Node.js)

Malcolm R. Kente — Thu, 21 Jan 2021 09:01:28 +0000

Whether you are new to software development or have been at it for a while, software testing is something you are likely to encounter. It is an integral part of any development process.

Unit Tests 🧪

There is an expectancy for developers to write unit tests for their application's code. Unit tests are the right way of testing the smallest unit of code within a system. Ideally, these are isolated pieces of code that exist in separate files on an application.

Unit tests consist of testing individual methods and functions of your software's classes, components, or modules. Unit tests are, in general, relatively cheap to automate and can be run very quickly by a continuous integration server.

The backstory 🔙

So recently, I've been improving some of the projects on my GitHub. One of the main points has been to increase the code coverage by writing unit tests for my projects.

I've become quite accustomed to using the Jest testing framework. Not a knock to any other testing frameworks, but Jest has become a recent favorite go-to of sorts. Thus I decided to implement testing using Jest on a Node.js project of mine.

Disclaimer ‼️ Mocha/Chai could've also been a viable option, but I wanted to play around the backend with Jest this time around. 🙈

My Problem 🤔

Something that kept repeatedly happening is similar assertions that came up for multiple modules.

Module 1️⃣

isNotNumber.helper.js

module.exports = (incomingId) => isNaN(incomingId);

isNotNumber.helper.test.js

const isNotNumber = require("../isNotNumber.helper");

describe("isNotNumber helper function unit tests", () => {
  it("should validate incoming module truthiness", () => {
    expect(isNotNumber).not.toBeNull();
    expect(isNotNumber).toBeTruthy();
  });

  it("should validate string type as true", () => {
    const results = isNotNumber("dummy")

    expect(results).not.toBe(false);
    expect(results).toBe(true);
  });

  it("should validate number type as false", () => {
    const results = isNotNumber(1)

    expect(results).not.toBe(true);
    expect(results).toBe(false);
  });
});

Module 2️⃣

isObjectPropertyEmpty.helper.js

module.exports = (incomingObject) =>
  Object.values(incomingObject).some((key) => key === null || key === "");

isObjectPropertyEmpty.helper.test.js

const isObjectPropertyEmpty = require("../isObjectPropertyEmpty.helper");

describe("isObjectPropertyEmpty helper function unit tests", () => {
  it("should validate incoming module truthiness", () => {
    expect(isObjectPropertyEmpty).not.toBeNull();
    expect(isObjectPropertyEmpty).toBeTruthy();
  });

  it("should validate object with empty field as true", () => {
    const results = isObjectPropertyEmpty({ id: "" })

    expect(results).not.toBe(false);
    expect(results).toBe(true);
  });

  it("should validate object with non-empty field as false", () => {
    const results = isObjectPropertyEmpty({ id: 1 }

    expect(results).not.toBe(true);
    expect(results).toBe(false);
  });
});

I realized quickly that this could be an issue that may repeat over time with many of the other modules. It probably is acceptable to re-write the same assertions in multiple tests, but it felt very impractical and not-very D.R.Y.

The Solution 💡

The thing that ended up being helpful was refactoring and creating "Helper Functions" that took care of covering the repeating assertions.

The process was as simple as:

Create a function(s) with the assertion logic in a separate file (use logical naming constructs). ✅
Call on the required helper when writing unit tests. ✅

Helper functions with assertion logic
validators.js

module.exports = {
  validateTruthiness: (received) => {
    expect(received).not.toBeNull();
    expect(received).toBeTruthy();
  },
  validateBooleanValues: (received, boolean) => {
    expect(received).not.toBe(!boolean);
    expect(received).toBe(boolean);
  },
  ....
}

Using helpers in the unit tests
isNotNumber.helper.test.js

const isNotNumber = require("../isNotNumber.helper");

const {
  validateTruthiness,
  validateBooleanValues,
} = require("../../../utils/validators");

describe("isNotNumber helper function unit tests", () => {
  it("should validate incoming module truthiness", () => {
    validateTruthiness(isNotNumber);
  });
  it("should validate string type as true", () => {
    validateBooleanValues(isNotNumber("dummy"), true);
  });

  it("should validate number type as false", () => {
    validateBooleanValues(isNotNumber(1), false);
  });
});

isObjectPropertyEmpty.helper.test.js

const isObjectPropertyEmpty = require("../isObjectPropertyEmpty.helper");

const {
  validateTruthiness,
  validateBooleanValues,
} = require("../../../utils/validators");

describe("isObjectPropertyEmpty helper function unit tests", () => {
  it("should validate incoming module truthiness", () => {
    validateTruthiness(isObjectPropertyEmpty);
  });

  it("should validate object with empty field as true", () => {
    validateBooleanValues(isObjectPropertyEmpty({ id: "" }), true);
  });

  it("should validate object with non-empty field as false", () => {
    validateBooleanValues(isObjectPropertyEmpty({ id: 1 }), false);
  });
});

Conclusion 🏁

That's pretty much it! Refactoring and introducing helper functions that took care of the assertion logic took away the need to repeat code.

As I soon found out, more tests also had identical assertions, so the need to have a test validation file became warranted. In the end, a single file housed all the validators used throughout the project.

I'm pretty sure other approaches to this situation I found myself in.

Let me know what you think about this?
And feel free to share any improvement tips for this. ✌️

Find the above code snippets 👉 here 👈
Full repo 👉 here 👈

What I Learned From Doing A 5-Day Coding Challenge

Malcolm R. Kente — Mon, 02 Mar 2020 11:35:59 +0000

What I Learned from doing a 5-Day Coding Challenge

Last week, I took part in organizing and doing a 5-Day Coding Challenge. The challenge focused on creating and submitting 1 HTML & CSS project a day. Each project could not contain any JS or JS frameworks.

Students of mine at Wild Code School Netherlands embraced the challenge with me. Over the course of a working week (Mon-Fri) we set upon tackling this. The purpose and idea behind the challenge were to:

Revisit the fundamentals of web development.
Get extra practice and deliver under a set deadline.
Motivate the creating of small projects for a developer’s portfolio.

The challenge followed suggestions provided by freeCodeCamp: https://www.freecodecamp.org/learn/responsive-web-design/responsive-web-design-projects/

Lessons From The Experience

After 5 days of delivering projects, I’ve looked back at my experience. I did use a lot of what I know on most of the projects. Despite my knowledge, I found myself learning and discovering new things. Below is a recap on the lessons learned:

Flexbox For The Win

I’m a huge fan of Flexbox and used this on most (if not all) of the 5 projects. It gives freedom to create complex layouts while using little declarations. This saves time and helped me create responsive pages without much effort.

.row {
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
  width: 100%;
}

.row_reverse {
  flex-direction: row-reverse;
}

.column {
  display: flex;
  flex-direction: column;
  flex-basis: 100%;
}

Mobile Parallax Woes (background-attachment: fixed)

On day 4, I realized that “background-attachment: fixed” is a total fail on iOS mobile devices. After some digging around (StackOverflow), I found out that this is disabled.

Fixed backgrounds have huge repaint costs and destroy scrolling performance. Although, I’ve seen the case not being the same for Android.

.hero {
  height: 100vh;
  display: flex;
  justify-content: center;
  align-items: center;
  flex-direction: column;
  background-color: #ffffff;
  background-image: url("../img/mally-dev.jpg");
  background-attachment: fixed;
  background-size: cover;
  background-position: top right;
}

This was a new and hard lesson learned. Most of the parallax effects I included in the projects used it. I’m looking forward to getting some time in the near future to fix this. It is something to consider when working on future projects.

Box-Shadows Give Depth

The box-shadow property can enhance the feel of web page elements. It can be used to add shadow effects both inside and outside an element. Using a comma can create multiple shadows.

.intro_text {
  text-align: center;
  padding: 5px;
  border: 1px solid var(--brand-black);
  width: 80%;
  background-color: var(--brand-white);
  box-shadow: 0.2em 0.5em 0 0 var(--brand-blue),
    inset 0.2em 0.5em 0 0 var(--brand-black);
}

@keyframes For Animation Control

Keyframe animations are similar to CSS transitions. They can be used to change the properties’ values. Unlike transitions, keyframes allow control of the in-between animation steps.

.hero h1::before {
  content: "FullStack Web Developer";
  animation: animate 5s alternate 0.8s linear infinite;
}

@keyframes animate {
  20% {
    content: "Hip Hop Nerd";
  }
  40% {
    content: "Coffee Lover";
  }
  60% {
    content: "Dancer";
  }
  80% {
    content: "Music Enthusiast";
  }
  100% {
    content: "World Citizen";
  }
}

This was good for creating text transformation animations for an element.

Collective > Solo

Doing this challenge was a good refresher. I learned a lot of new things that I previously didn’t take time to dive into. The fact that my students joined in on this challenge improved the experience. It created a true collective feeling between everyone on the campus. We all went through the same process and could relate to the problems others faced.

In circumstances where people got stuck or couldn’t move forward, help was offered. Ideas and tips were also shared between everyone who took part. In the end, comradery and the feeling of accomplishment were achieved.

Conclusion

Coding challenges are a great way to learn and re-learn concepts. The limitation of time also forces a habit of prioritization. In this case, the user stories help in creating a working structure for the developer.

This was definitely the case for me during the 5 days spent creating. After this past experience, I’m looking forward to attempting more challenges. It’s a good way for any developer at any stage of their career to polish and fine-tune their skills.

Feel free to check out the repo of the 5 Day Coding Challenge Week here: https://github.com/reMRKableDev/5-day-coding-challenge

I’ve documented my progress under the “mrk-progress” branch: https://github.com/reMRKableDev/5-day-coding-challenge/tree/mrk-progress

Check out everyone who took part in it so far here: https://github.com/reMRKableDev/5-day-coding-challenge/network/members