DEV Community: john-easyagile

Empowering Developers: Why I Built Emulative, a VSCode Extension for TypeScript Type Mocking

john-easyagile — Thu, 13 Apr 2023 05:33:29 +0000

As a developer, I'm passionate about finding ways to make coding faster, easier, and more enjoyable. One of the challenges that us developers face is writing tests for our code. Testing is crucial for ensuring that your code works as intended, catches bugs early, and allows you to refactor with confidence. However, writing tests can also be a time-consuming and tedious task, especially when it comes to mocking data.

Mocking data is the process of creating fake or simulated data that mimics the real data that your code interacts with. Mocking is essential for unit testing, integration testing, and end-to-end testing, as it allows you to isolate and test individual parts of your code without relying on external dependencies or environments. However, mocking can also be a difficult and error-prone task, as it requires you to create complex data structures that match the shape and types of your code.

That's why I built Emulative, a VSCode extension that helps developers speed up testing by creating mock objects representing TypeScript types. Emulative is designed to empower developers to focus on writing tests instead of struggling with mock data.

I built Emulative with the developer community in mind. I wanted to create a tool that would be useful, intuitive, and accessible for all types of developers, from beginners to experts. I believe that testing should be an integral part of the development process, not an afterthought or a chore. Testing helps developers to catch bugs early, prevent regressions, and ensure that their code is reliable and maintainable. Testing also helps developers to learn and understand their code better, as it forces them to think about edge cases, assumptions, and behaviours.

Emulative is a tool that can help developers of all levels to write better tests faster. With Emulative, you can easily generate mock data for most TypeScript types, including primitives, arrays, objects and interfaces. Emulative uses TypeScript's type system to infer the shape and values of the mock data, so that you don't have to manually create and maintain it.

I built Emulative because I wanted to make a positive impact on the developer community. Emulative is open-source and free to use, and I welcome feedback, suggestions, and contributions from anyone who shares my passion for coding and testing.

Happy testing!

4 hacks for writing frontend tests 10x faster (probably!)

john-easyagile — Fri, 02 Sep 2022 03:20:25 +0000

We all know writing unit tests is important but sometimes it feels like it can take up more time than the feature work itself. I’ve found a couple of handy hacks that I feel have increased my speed when writing tests whilst also improving their quality and, being the kind fellow I am, I’m going to share those with you:

Hack 1: Use Testing Playground

I guess the first tip in this article is - use Testing Library. I didn’t make this its own point because it is already so popular. But if you are not using it yet, make sure you do!

Unit testing with Testing Library is really easy and intuitive. Despite this, it can still be challenging to find the right queries or to understand why an element isn't being matched.

Enter Testing Playground.

Testing Playground allows you to render a component in a sandbox providing you with direct visual feedback of the component. It also allows you to interact with the rendered component to come up with the best queries to select elements. And, like Testing Library, everything it does is with accessibility (a11y) in front of mind so it teaches you about the importance of a11y and best practices while you use it.

There are many ways you can use Testing Playground including a chrome extension and a browser based app.

The best way I have found which has been an absolute time saver for me though is by invoking screen.logTestingPlaygroundURL() right from the test block itself. I usually find myself doing this as soon as I get the component rendering, just to get the lay of the land and work out what parts of it my test might like to interact with.

Hack 2: Use test.todo

Please don’t jump down my throat, but I have tried Test Driven Development and didn’t like it. Like anarchism, I think it sounds awesome in theory, but found that it actually slowed down my development cycle when I tried to implement it.

I still like the idea of getting some thinking about testing down before I finish building a feature though and have settled on a process that, for me, seems to work well and keep my development moving along.

I now use Jest’s test.todo to record what I am going to test as I am planning to and building out a feature (Big thanks to Karl for first introducing me to the idea!).

My usual process goes a bit like this. First I capture the requirements spelled out for me by my awesome Product Owner (Hi Biz!) in test.todo form, like a todo list. Then, as I am building and encounter other edge cases and important testing areas I add these as test.todo’s too. That way, when it comes to testing time, I have thought through a lot of what I am going to test and am less likely to miss testing edge cases or important functional requirements.

A simple example for a test.todo for the following <UserDetails /> component:

import React from "react";

export interface User {
  firstName: string;
  lastName: string;
  username: string;
  emailAddress: string;
  SEN: string;
}

export interface ShowHideUserDetailsProps {
  showDetails: boolean;
  user: User;
}

const UserDetails = ({ showDetails, user }: ShowHideUserDetailsProps) => (
  <>
    {showDetails ? (
      <div>
        <h1>User Details</h1>
        <ul>
          <li>{user.firstName}</li>
          <li>{user.lastName}</li>
          <li>{user.username}</li>
          <li>{user.emailAddress}</li>
          <li>{user.SEN}</li>
        </ul>
      </div>
    ) : (
      <div>
        <h1>Privacy Protected</h1>
      </div>
    )}
  </>
);
export default UserDetails;

Might be as follows:

describe('<UserDetails />', () => {
  test.todo('Should show user details when show details is true');

  test.todo('Should NOT show user details when show details is false');
});

Hack 3: Use builder functions

I used to find myself creating objects for each test to mock out values for testing. Then I wrote another component which used the same object and mocked it out again there. There’s got to be a better way, I thought. And Matt Smith at FinoComp introduced me to one.

I now use builder functions which return commonly used object types in testing and which allow properties to be overridden everywhere. There is certainly a little bit of extra time needed to set them up but I find that, once they are done, the next time you have to interact with that object you are so glad they are there. For example, for a given TS interface:

export interface User {
  firstName: string;
  lastName: string;
  username: string;
  emailAddress: string;
  SEN: string;
}

export interface ShowHideUserDetailsProps {
  showDetails: boolean;
  user: User;
}

You might have a builder function that looks like this:

export const buildShowHideUserDetailsProps = (overrides?: Partial<ShowHideUserDetailsProps>): ShowHideUserDetailsProps => {
  const defaultShowHideUserDetailsProps = {
    showDetails: false,
    user: {
      firstName: "Jazmyne",
      lastName: "Jacobs",
      username: "Kylee_Skiles37",
      emailAddress: "Rashawn13@gmail.com",
      SEN: "SEN-123456"
    }
  };

  return { ...defaultShowHideUserDetailsProps, ...overrides};
};

There are some limitations to this pattern, however, as they become less useful with deeply nested object types. Additionally, they do require some upkeep when object types change in the codebase which brings me to my next point...

Hack 4: Use a tool to mock your Typescript types

Look, I’m going to be straight here. This is the part where I plug my own work but at least I left it for last, right?

Whenever I found myself creating another mock object for testing I kept looking at my Typescript types and thinking, can’t something look at that and do it for me? This sent me down a search for a solution and I was so stoked to find intermock which is a command line tool that does just that. While it is still a work in progress and has some limitations I have found it super helpful when writing tests.

I did find using the combination of the CLI and copy/pasting from the terminal a little cumbersome though. How could I make this even easier I thought.

Enter my VSCode extension, Emulative. Simply select your type name, run a command through the Command Palette in VSCode and you can use Emulative to produce Typescript objects, Json objects or the aforementioned builder functions from Typescript types. These are automatically copied to the clipboard but the plain objects can also be sent to a new scratch file.

But wait, there’s more! Where I work at Easy Agile we have a bunch of properties we work with from Jira which aren’t accurately represented by string or number. With Emulative you can set up key/value pairs which will overwrite any matching properties which are found in your types.

Shout out to Easy Agile for giving me the time, resources and encouragement during an Inception Week to work on Emulative!

Well, that’s it for me, I hope you find some of these tips and tricks useful for speeding up front end testing.

Either way please feel free to sound off in the comments about nifty tricks you have found to improve your unit testing speed (or just how wrong I am about TDD).

Hi 👋 I'm John, a developer and psychologist at Easy Agile. When I'm not building products customers love to use, you will usually find me in the surf with my wife and daughter, spending too much time agonising over my coffee grind size or walking my golden retriever Norman.

If you want to ask me more about Inception Weeks or chat about anything else agile, software development (or surfing!) reach out on Twitter.

Why I'm stoked on Inception Weeks 🤙 (and your employee's will be too!)

john-easyagile — Thu, 21 Oct 2021 08:30:25 +0000

One of the things that most intrigued me about Easy Agile when I was looking to apply was the opportunity to take part in regular Inception Weeks.

For those of you not familiar with the concept, it is, at least as defined by Easy Agile, one week in every five where employees across the company can work on a project of their own design. The only guardrail being that the Inception Week project will leave us thinking “how did we ever live without this?!”

"Deliver value, let it be messy, give us the opportunity to get feedback" Dave Elkan, Easy Agile co-CEO

The aim of Inception Weeks is always to ship real value at the end of the period with a favourite quote of mine from our co-CEO Dave “Deliver value, let it be messy, give us the opportunity to get feedback”. Despite this Easy Agile also prescribes to the mantra of learning by failing, giving room for employees to be experimental and stretch themselves in their projects.

It sounded too good to be true, like some Silicon Valley fantasy world that would only ever be found on TV. Surely no company would actually let me work on whatever I wanted for such a large chunk of my working time? What would the benefit be to them?

My first Inception Week felt like it came around fast when I first started at Easy Agile. Despite this I was ready. Although I was new to the company I was not new to their applications, having used Easy Agile User Story Maps daily in my previous role. I knew exactly what I wanted to work on, a way to help teams to estimate their capacity from their previous velocity when in team planning. I searched the Inception Week backlog (where these ideas are captured) thinking that surely I had stumbled onto something new but, alas, there are no original ideas. Turns out our co-CEO Nick had already come up with the idea at least two years before I started.

Never mind that though, I dived into the project with vigour, coming out of my first Inception Week with a working prototype I was able to demonstrate to the team. More than that, I quickly ramped up my knowledge about the codebase since I was working on my own idea with the permission to be messy and fail. I can’t imagine another approach that would have got me up to speed so quickly as a productive and useful member of the team. While the work I did has not (yet) made it to production, it has informed similar functionality in other Easy Agile applications, improved our combined knowledge of the area and will be useful as a prototype we can demo to customers when building such a feature becomes a business priority.

The next of my Inception Week projects, Easy Agile Jira Hero, was arguably an even greater success for myself and Easy Agile as it has just won third place in Atlassian’s Codegeist hackathon’s IT Category using a cutting edge development platform called Forge. I am hopeful that this outcome will help extend Easy Agile’s reputation as a company that is not afraid of trying new things while being one of the premier providers of software in the Atlassian ecosystem. On top of that, as a company and individuals, we gained invaluable knowledge around Forge applications we can use to better service our customers in the future.

Although the initial idea was barebones, it was elevated through the work of my amazing teammates. We had a blast making it too, building our cohesiveness as a team and having fun indulging our inner nerds with a vintage 8 bit design concept complete with parallax’s and funky animations.

My most recent Inception Week has helped me grow significantly as a developer as I worked on an application outside of the browser for the first time in my career. Building on the work of the awesome folks who built intermock, I adapted their tool to be used within the VSCode IDE with the extension Emulative (coming soon to a marketplace near you!). In doing so, I am hoping to do my (very) small part to improve the lives of my fellow developers by building upon the tool chain that so many others have built in order to make the work we do easier and more rewarding.

Looking back on my Inception Weeks with Easy Agile I can now easily see their benefit to both the employees and the business.

As employees, Inception Weeks empowered us to think creatively, learn and grow. They also contribute to a wonderful cadence of work. They allow us to take the foot off the pedal of the usual feature development cycle, complete with cutting out all meetings, leading to improved mental health and motivation.

The business benefits too, in varied ways, big and small which are both expected and unexpected.

Inception Weeks no doubt leads to a healthier, happier and more productive workforce. They also contribute enormously to developing a positive and inclusive team culture by breaking down the walls between teams as we form new teams for a week around things we are passionate about.

Another way Easy Agile benefits as a business relates to the quote attributed to Henry Ford “If I had asked people what they wanted, they would have said faster horses.” Easy Agile is good at building awesome stuff that their customers want. But in an environment as competitive as software in general, and the Atlassian ecosystem in particular, innovation is particularly important. Inception Weeks empower the team to identify their own problems and come up with creative solutions leading to new tools, features and even products for the business.

If you are a business involved in the software space, or any space really, I recommend you take a serious look into how Inception Weeks could become part of your business. Your future self and your employees will thank you for it.

Also, if Easy Agile’s Inception Weeks sound as awesome to you as they did to me take a look at our open positions, we are hiring!

Hi 👋 I'm John, a Developer and Psychologist at Easy Agile. When I'm not building products customers love to use, you will usually find me in the surf with my wife and daughter, spending too much time agonising over my coffee grind size or walking my golden retriever Norman.

If you want to ask me more about Inception Weeks or chat about anything else agile, software development (or surfing!) reach out on Twitter.

My journey from psychologist to software developer

john-easyagile — Wed, 14 Apr 2021 10:58:23 +0000

Originally published on the Easy Agile blog on 23 March 2021

We’re checking the surf and haven’t talked in a while. Two sets of eyes locked on the ocean, is it worth paddling out this windy winter morning?

“Where are you working now?” you ask distractedly. “I’m actually a software developer.”

Your eyes break from the swell, instinctively looking for signs of trauma or burnout. “Wow, you couldn’t have picked something more different!” you say, a little taken aback.

I have had some version of this conversation over and over since I made the switch from psychology to coding. People are often confused by how certain I am that I made the right choice, despite the fact that in my mid-thirties and around the birth of my first baby I discarded a lucrative career I spent a lot of time and effort pursuing, and to which I seemed to be well suited.

The truth is that making that change when I did vastly improved my health and my family's happiness. It was a privilege to work with my clients and share their innermost secrets, hopes and dreams. It was also extremely traumatic and disheartening, and was wearing me down. Then one day my wife said, “you don’t have to be a psychologist you know?” It may seem obvious, but that short sentence opened my mind.

I started to think about what else I might like to do. I’d always envied friends of mine who were carpenters or bricklayers and seemed to get so much satisfaction in gradually mastering their craft. Problem is, I am terrible with tools and can’t hammer a nail to save my life. A chat with a friend who is a coder where he spoke about his craft in the same way got me thinking.

I took a free online course to test the waters and was instantly hooked. I had to fight myself to go to bed at a decent time every night as I learned more and more about topics like CSS, browsers, clean code and asynchronous javascript. A couple of weeks later I started my masters in Information Technology and threw myself into it.

Ok, I thought, there is no way better to learn than on the job so I reached out to every company I could find within driving distance, offering to do anything even tangentially related to coding to get my foot in the door.

Thankfully, the Wollongong tech community (Hey there Siligong!) is open minded and two awesome companies, first FinoComp and now Easy Agile were able to look past my non-traditional background to see my potential.

I’m now a bonafide front end developer and am absolutely stoked to work everyday, expanding my toolset and honing my craft to build awesome products for our customers which improve their lives.

To anyone out there who is considering a career change, it’s never too late. It changed my life for the better and it could change yours too.

“The journey of a thousand miles begins with one step” Lao Tzu.

(Oh, you should definitely paddle out in that surf too. No matter the conditions a surf is always a good idea.)

Foo Bar Nah

john-easyagile — Tue, 13 Apr 2021 01:20:07 +0000

Originally published on the Easy Agile blog on 9 April 2021

I bent over my desk in frustration, suppressing the urge to scream so as not to upset the rhythmic clack-clack of my coworkers. I’d been frustrated all morning by a particularly nasty React infinite re-rendering issue that I just couldn’t get working. The urge to scream came when, my own toolbox exhausted, I turned to Google.

You see, it looked like someone else had come across the same issue and had decided to record a solution for prosperity (and internet points). I eagerly scanned the page for the sample code that would save my morning. Finding it, my eyes were drawn to the dreaded fooBarBaz and I knew my morning was about to get a whole lot worse before it got better.

I actually love the history of programming and the little easter eggs fellow developers have passed down (my personal favourite - I am a teapot). These help to make this job interfacing with computers much more fun and human. I can appreciate that the practice of using fooBarBaz in naming example functions and variables has a long and storied tradition dating back at least to the Tech Model Railroad Club at MIT circa 1960. I acknowledge that the use of fooBarBaz is primarily not to introduce any distractions from the point which is being demonstrated. I also think that we should pretty much stop using them.

I am always awed by the amount of information my fellow developers have left out there for me on the internet. So many people in this field seem to have an innate need to help others, leading them to put in countless hours to fill Stack Overflow and blogs with useful information. I can only imagine that the people putting in their time and effort to this end are hoping that their efforts will help as many people as possible. fooBarBaz gets in the way of that.

Let me take off my developer hat for a second and put on my recently discarded, slightly misshapen and battered psychologist one. Interweaving complex facts into stories is a time tested technique which facilitates learning. Here in Australia, the technique has been used for tens of thousands of years by the Australian Aboriginal and Torres Strait Islander peoples to help them to remember important and complex information such as the locations of waterholes across vast tracts of inhospitable desert. Our brains are networks of interconnected neurons so we are more likely to hold on to what we have learned when we are able to integrate new information into our current knowledge base. The modern term for this is associative learning.

Additionally, as I’m sure you’ll remember from school, keeping learning interesting has been demonstrated to be a powerful motivator which energises learning.

When we take all this time and effort to communicate with our fellow developers we can and should harness the advantage of associative learning and intrinsic motivation to make sure that the information we are putting out there is as useful as possible to as many people as possible. To this end I believe that we should give as much thought to meaningful naming when creating example code as we do in our own codebases.

Marijn Haverbeke’s Eloquent Javascript regularly comes at the top of lists of books you should read when learning Javascript (JS). It is no coincidence that he is also a master at using meaningful names to help people to better understand coding principles. When teaching new programmers about string comparison in JS he uses the following example:

console.log("Itchy" != "Scratchy");
// → true

Marijn piggybacks off our existing knowledge about Springfield’s favourite cartoon characters to give extra meaning and interest to this example. We know that Itchy and Scratchy are a mouse and cat respectively and so most definitely not the same.

Consider the same example but rendered with the dreaded Foo/Bar instead:

console.log("Foo" != "Bar");
// → true

To seasoned developers, this might be easy enough to parse: you’ve read hundreds of examples like this and so have learned the association between Foo and Bar and internalised it. But this creates a barrier for learning for new developers who have not yet internalised this rule and instead increases the mental load for them to understand the concept. It also misses out on creating that little spark of interest or joy to help pique the reader's interest and so increase their motivation to understand the underlying concept.

I am not saying there is absolutely no place for fooBarBaz (although I think their utility is limited). The best way to use these terms is to emphasise that anything could be put in a certain place. An example of this is when we’re talking about arguments and parameters in JS functions. You see, there is no type checking in vanilla JS and so if we have a function like the following that takes a parameter and simply logs its value to the console, it doesn’t matter what type of argument we pass in:

const consoleLogParameter = (foo) => {
  console.log(foo);
};

const bar = “bar”;
const baz = 42;

consoleLogParameter(bar);
// → “bar”;

consoleLogParameter(baz);
// → 42;

I believe that these terms have the most utility in this case as their purpose is to emphasise that their type doesn’t matter. I would also add the caveat to this that using these terms in this way is only suitable when you are producing content for experienced developers who are going to have built a working understanding of these terms.

Even if this is aimed at experienced developers, I still believe that more meaningful names would be better in this example:

const consoleLogParameter = (anyTypeOfData) => {
  console.log(anyTypeOfData);
};

const name = “Homer Simpson”;
const age = 39;

consoleLogParameter(name);
// → “Homer Simpson”;

consoleLogParameter(age);
// → 39;

Another example where more meaningful variable names would be useful is in relation to metasyntactic variables. These variables are commonly found in source code and are intended to be modified or substituted before real-world usage. Whilst these variables are only placeholders, I believe that it is also better to use a variable name which offers more context to your developer comrade to assist them when they are reading and implementing the code in future.

We work in a wonderful profession with a rich history, where many people are willing to donate their time to helping to educate and mentor their fellow programmers. Using meaningful variable names in place of fooBarBaz is one way that we can ensure that this effort is worthwhile and helps as many people as possible. It lowers the barriers to entry for the profession, helping to create a more diverse and welcoming programming community.

So ditch the fooBarBaz (but not the Teapot) and go forth and spark joy!