DEV Community: Mei

My Journey as a Hard of Hearing Software Engineer

Mei — Sun, 04 Feb 2024 22:06:13 +0000

Being a software engineer with a hearing challenge has been a rollercoaster of ups and downs, but let me tell you, the ride is worth it! Just a quick background of myself, I have a profound hearing loss in my left ear and am deaf in my right ear.

One of the biggest hurdles I faced was the constant chatter in the tech world.. M.E.E.T.I.N.G.S. I know we all have a love-hate relationship with them. Sitting for hours, listening to your colleagues about the updates, production issue and knowledge transferring. I genuinely hate meetings, because meetings making it tricky for someone like me. Catching every detail in a fast-paced conversation was really tough for me, and sometimes it felt like I was always missing out!

To tackle the challenges, I use visual tools and written communication apps, Microsoft Team live transcription is my favourite one! This very useful for reviewing discussions and ensuring that no important information is missed. They are my superhero!

Sure, there were tricky moments. Understanding everyone in a fast conversation or catching every detail can be tough. But hey, the victories are sweeter than the challenges. Completing projects, working smoothly with teams and watching my code come alive are the best feeling.

If you are someone who is just starting to code, always believe in yourself. Everything is possible, and it doesn't matter if you're hard of hearing or deaf – you've got what it takes. Don't be afraid to ask questions. Seeking help is a strength, not a weakness.

Join coding communities, both online and offline, to connect with fellow learners and experienced developers. Embrace the challenges as opportunities to grow, and remember that progress takes time. Celebrate small victories along the way, and build a supportive network that encourages your coding journey. Stay curious, stay persistent, and most importantly, enjoy the process of learning and creating.

Go ahead, embark on this exciting adventure with confidence, because you have the power to shape the future. Embrace your uniqueness, be resilient in the face of challenges, and remember – coding is for everyone!✨

Test-driven development with React and React Testing library

Mei — Thu, 12 Aug 2021 21:32:07 +0000

Test Driven Development or TDD is essentially the development practice of writing your unit tests before your code. You write failing unit tests, then write the code to make it pass; refactor the code if necessary and repeat.

Test Driven Development is a core part of software development practice. Testing gives us confidence, and confidence allows us to move fast, deploy daily and that quickens the feedback loop with our members.

This article is not a complete introduction to testing in React or React Testing Library. There are much better introductions available for these technologies elsewhere on the web; although you should be able to follow along without knowing these in much depth.

Instead I am going to explore my approach to TDD in our React application. I will talk about some of the techniques and rules when building React components.

Before we can start writing tests, and the code to pass them, we have decide what we should be testing when writing React components. As the creator of React Testing Library himself, Kent C. Dodds says, you should endeavour to make your tests as similar to how users (human or other systems) use your software.

What does this mean in practise? Users don't care about the implementation of your components, only that they work as expected. Your tests should do the same. We try to mock as little as possible, avoid testing implementation details and focus on covering all the use cases we want our component to solve.

How does this help us when we are using TDD? First consider the use case you are trying to solve, document it as a test, then write some code in your component to pass that test (without breaking the others). This forces us to completely understand and verbalise the reason for our component; this is useful for you, and anybody who wants to understand your code after you.

This is also consistent with the Behaviour Driven Development (BDD) approach as we are driving our design and implementation by the behaviour of our application. However following Kent's rule above, good tests are behaviour driven tests.

Show me the Code!

Code Sandbox with components and tests

An example is worth a thousand words, so we'll consider the use case of writing a component that allows a user to send us their email address (because everybody loves forms, right?)

Let's start with our first use case, and our first test. It's always good to start with the happy path so let's make sure if a user enters their email in a form, and clicks a submit button, our form gets submitted successfully.

test("form submits when valid email entered", () => {
  const handleSubmit = jest.fn();
  const { getByLabelText, getByText } = render(
    <EmailForm onSubmit={handleSubmit} />
  );
  const emailInput = getByLabelText(/enter email/i);
  const submitBtn = getByText(/submit/i);

  fireEvent.change(emailInput, { target: { value: "test@test.com" } });
  fireEvent.click(submitBtn);

  expect(handleSubmit).toHaveBeenCalled();
});

Notice also that the handleSubmit function is mocked despite one of our suggestions being to mock as little as possible. One of the best candidates for mocking is backend interaction. Because this component is not responsible for how the email input is send to our backend systems, this is mocked out and we just want to ensure it is called correctly.

A good way of evaluating your tests is to consider what happens if you refactor your components without changing their functionality (by changing variable names, algorithms etc). Good tests should not be tightly coupled to their implementation, as long as the functionality is consistent. By writing these semantic queries into your front end tests, we can also ensure that our components are accessible by default.

Now that we've written a test that we're happy with, we can write the code in our component to pass this test. The goal of this component should only be to pass this test. It will need to pass a submit function when an email is entered and submit button clicked, but at this point we don't need to worry about any validation.

function EmailForm({ onSubmit }) {
  return (
    <form
      onSubmit={(e) => {
        e.preventDefault();
        onSubmit();
      }}
    >
      <label htmlFor="email">Enter email:</label>
      <input id="email" type="text" />
      <button type="submit"> Submit </button>
    </form>
  );
}

Great, now we have a working email entry field. Any consumer of this component; or new developer can open the test file, see what this component does, prove it works and use/extend it confidently. 👍

Let's extend this component now and build in validation on the email field to ensure we have a valid email address before we allow a submit.

test("form shows an error if invalid email entered and does not call submit", () => {
  const handleSubmit = jest.fn();
  const { getByLabelText, getByText, getByTestId } = render(
    <EmailForm onSubmit={handleSubmit} />
  );
  const emailInput = getByLabelText(/enter email/i);
  const submitBtn = getByText(/submit/i);

  fireEvent.click(submitBtn);
  expect(handleSubmit).not.toHaveBeenCalled();

  fireEvent.change(emailInput, { target: { value: "notvalid" } });
  expect(getByTestId("email-error").textContent).toBe(
    "Please enter a valid email"
  );

  fireEvent.click(submitBtn);
  expect(handleSubmit).not.toHaveBeenCalled();
});

This test uses similar queries and events as the previous test, but is ensuring that if the email field is blank or contains an invalid email address, the onSubmit function will not be called, and an error message is shown.

In this test we also set up the query for our error message with a test-id instead of using a semantic query such as getByText. Test-id's are the best selector for this case as the text is dynamic and there is no standard semantic query to use for errors, although we prefer semantic queries we should still use the most sensible query for each object we are trying to get.

Now that we've written a test that captures our second use case, let's update our component to pass this test.

export default function EmailForm({ onSubmit }) {
  const [formValid, setFormValid] = useState(false);
  const [emailError, setEmailError] = useState();

  const validateEmail = (e) => {
    const email = e.target.value;
    if (!email || email.indexOf("@") === -1) {
      setFormValid(false);
      setEmailError("Please enter a valid email");
    } else {
      setFormValid(true);
      setEmailError();
    }
  };

  return (
    <form
      onSubmit={(e) => {
        e.preventDefault();
        if (formValid) {
          onSubmit();
        }
      }}
    >
      <label htmlFor="email">Enter email:</label>
      <input id="email" type="text" onChange={validateEmail} />
      {emailError && <p data-testid="email-error">{emailError}</p>}
      <button type="submit"> Submit </button>
    </form>
  );
}

We can update this component by adding a validation function to run onChange on the input. This will ensure that the validation runs before the form is submitted, therefore passing our test. Where there is a validation error, this gets passed to a variable stored in state (using React Hooks) and there is a conditional render to render out any error messages, that uses the

data-testid="email-error"

tag we discussed in our test design.

Notice that our test does not read the state of our component, or care if we implement the validation using the onChange handler, this is all implementation details, and there are many other ways we could refactor this component, or add a form library without breaking the tests.

Conclusion

I hope this example shows how the TDD cycle can work in the context of React components, as well as showing some of the test design considerations that you an use in React Testing Library tests to make your tests both useful and robust.

This article also only covered writing specific unit tests for individual components, for integration tests, we will use very similar rules, For a complete testing strategy I use end-to-end Cypress tests, and a good end to end testing setup should be used with well tested components to give complete confidence in your code.

How to write a good ReadMe.

Mei — Mon, 26 Jul 2021 18:53:15 +0000

What is a ReadMe?

“A README is like the face of your project. It is the first file a person should read whenencountering a source tree, and it should be written as a very brief and giving very basic introduction to the software” - A Beginners Guide to writing a Kickass README

A good quality README should:

help people engage in the project as well
get the attention of users better since it is a direct way to explain why this project matters, and why people should use and contribute to the project
help a new user get started, e.g. how to compile, how to install, and how to start integration

So, what makes a good Readme?

Project Title/Motivation – usually some sort of short concise description of the project. This can reference other documents (like requirements) if need be.
Getting Started - These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.
- Prerequisites (any additional libraries needed to be installed)
- Step by step guide to getting the project started in a dev environment
Running Tests and/or Test Strategy - Explain how to run the automated tests in the project/system.
Deployment – Notes on how to deploy this on a live system
Versioning – Any comments on versioning system, link to tags etc.
Contributing – Details on code of conduct/team agreements.
Authors – list of all authors (sometimes indication of who started the project).
Licensing – details of licencing agreement (possible link to licensing file).
Acknowledgements – details of any acknowledgements, inspiration, etc.

To start with your Readme file, why not take a look at this website? 😊 https://readme.so/editor

Being a deaf/hard-of-hearing developer in tech industry

Mei — Mon, 12 Apr 2021 20:44:04 +0000

Hello, world! Not tech-related topic but, for those devs who have hearing difficulties, I have a question for you.

What are the challenges you faced in the tech industry during the pandemic?

I would love to hear your stories in the discussion section below :)