4 hacks for writing frontend tests 10x faster (probably!)
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.
// Example typeinterface User { firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;}interface ShowHideUserDetailsProps { showDetails: boolean; user: User;}// Builder pattern to build a mock object for the// ShowHideUserDetailsProps typeexport 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).
Related Articles
CompanyA day in the life of Jamie
It's a Monday morning and I’ve just pulled into the Kiama train station carpark.
It’s a short commute to the Wollongong CBD, where I am greeted by the team as I enter the office.
We start the day with a morning huddle in which each of us shares something good that’s happened during the last 24 hours, what we’re going to be working on that day and whether we’ve come up against any blockers.
The entire team then takes a walk down to local cafe, Beast, and get a coffee together. It’s a wonderful way to start the day, with a group of inspiring people.
For me, customer support is up next and I am super keen to get into helping our customers on their day’s journey with our product. My past experience in customer support has shown me just how much customers appreciate timely and helpful responses. It can really change a person’s day.
When customers have been responded to, I continue with my daily work using Easy Agile tools. I can say for sure this does make managing and working through sprints much easier.
I’ve got great team mates; if I want to discuss something, get some feedback or pair up, my colleague Matt is always there to help. Here he is:
He is genuinely an advocate for software craftsmanship and I'm totally onboard with this approach.
Around noon, we all stop for lunch. Some of us will get takeaway from the local mall, and others will bring something from home, but generally we all sit together and enjoy each other's company. On Fridays the street market draws the attention of most of us. There will usually be a session on the Switch - Mario Kart or Smash Bros the most popular choices.
It’s back into things after lunch and I have a check-in with Dave to see how things are going. We discuss my journey so far and what my ideas are for our upcoming inception week.
It's great to be able to sit down and talk about how we can make our systems better and improve the day-to-day work for our team.
There’s a few more things to get done and then it’s time to head to the station for the commute home. Matt and I chat about software architecture and almost miss the train.
When I look back over the last couple of weeks at Easy Agile, what stands out is the culture and the values of the team.
The commitment to integrity, honestly, inclusion and work philosophy is truly inspiring and uplifting. Never in my experience have I started a work day where everyone shares something positive. it really sets the tone for the following hours.
Easy Agile is an amazing company, especially when I compare it with my experiences over the last 20 years in manufacturing, customer support and software development. The team at Easy Agile practically demonstrate a holistic approach to both work and life which is equally refreshing and encouraging.
Workflow8 Software Development Methodologies Explained
Software development teams are known for using a wide variety of agile methodologies, approaches, and tools to bring value to customers. Depending on the needs of the team and the product's stakeholders, it’s common for teams to deploy and utilize a combination of software development methodologies.
Most dev teams combine methodologies and frameworks to build their own unique approach to product development. You’ll find there are plenty of overlapping principles from one methodology to the next. The key is choosing a system and working as a team to fine-tune and improve that approach so you can continue to reduce waste, maximize efficiency, and master collaboration.
In this post, we’ll outline and compare the following eight software development processes:
1. Agile software development methodology
2. Waterfall methodology
3. Feature driven development (FDD)
4. Lean software development methodology
5. Scrum software development methodology
6. Extreme programming (XP)
7. Rapid application development (RAD)
8. DevOps deployment methodology
1. Agile software development methodology
Agile is the most common term used to describe development methods. It’s often used as an umbrella term to label any methodology that’s agile in nature, meaning an iterative process that reduces waste and maximizes efficiency.
Most software development methodologies are agile with a strong emphasis on iteration, collaboration, and efficiency, as opposed to traditional project management. It’s like comparing jazz to classical music. 🎷
Traditional, linear management methods, such as the waterfall method we’ll cover below, are like classical music, led by one conductor who has a set plan for how the music should be played. The agile process, on the other hand, is more like jazz, which comes together through collaboration, experimentation, and iteration between band members. It’s adaptive and evolves with new ideas, situations, and directions.
2. The waterfall methodology
The waterfall approach is a traditional methodology that’s not very common in software development anymore. For many years, the waterfall model was the leading methodology, but its rigid approach couldn’t meet the dynamic needs of software development.
It’s more common to see the waterfall method used for project management rather than product development. At the beginning of a project, project managers gather all of the necessary information and use it to make an informed plan of action up front. Usually, this plan is a linear, step-by-step process with one task feeding into the next, giving it the “waterfall” name.
The approach is plan-driven and rigid, leaving little room for adjustments. It’s more or less the opposite of agile, prioritizing sticking to the plan rather than adapting to new circumstances.
3. Feature driven development (FDD)
Feature driven development is also considered an older methodology. Although it uses some agile principles, it’s viewed as the predecessor of today’s agile and lean methodologies.
As the name says, this process focuses on frequently implementing client-valued features. It’s an iterative process with all eyes on delivering tangible results to end users. The process is adaptive, improving based on new data and results that are collected regularly to help software developers identify and react to errors.
This kind of focused agile methodology can work for some teams that want a highly structured approach and clear deliverables while still leaving some freedom for iteration.
4. Lean software development methodology
Lean software development comes from the principles of lean manufacturing. At its core, lean development strives to improve efficiency by eliminating waste. By reducing tasks and activities that don’t add real value, team members can work at optimal efficiency.
The five lean principles provide a workflow that teams use to identify waste and refine processes. Lean is also a guiding mindset that can help people work more efficiently, productively, and effectively.
The philosophies and principles of lean can be applied to agile and other software development methodologies. Lean development provides a clear application for scaling agile practices across large or growing organizations.
5. Scrum software development methodology
Scrum is a system regularly used by software development teams. Like many software development methodologies, Scrum is agile, focusing on a value-driven approach. The Scrum process is based on empiricism, which is the theory that knowledge comes from hands-on experience and observable facts.
One Scrum takes place over a preset amount of time called a sprint. Usually, the time frame is between two to four weeks and the Scrum is at the beginning of the sprint. The goal of each sprint is to yield an imperfect but progressing version of a product to bring to stakeholders so that feedback can be integrated right away into the next sprint.
The specific goals of each sprint are determined by a product owner who orders and prioritizes backlog items (the artifacts that need completion). The sprint process repeats over and over again with the development team adjusting and iterating based on successes, failures, and stakeholder feedback.
Learn more about Scrum — the complete program planning solution for Jira.
6. Extreme programming (XP)
Extreme programming, also called XP, is a methodology based on improving software quality and responsiveness. It’s an agile approach that evolves based on customer requirements; the ultimate goal is producing high-quality results. Quality isn’t just limited to the final product — it applies to every aspect of the work, ensuring a great work experience for developers, programmers, and managers.
Decision-making in extreme programming is based on five values: communication, simplicity, feedback, courage, and respect. The specifics of XP can’t apply to all situations, but the general framework can provide value no matter the context.
7. Rapid application development (RAD)
Rapid application development (RAD), sometimes called rapid application building (RAB), is an agile methodology that aims to produce quality results at a low-cost investment. The process prioritizes rapid prototyping and frequent iteration.
Rapid application development begins with defining the project requirements. From there, teams design and build imperfect prototypes to bring to stakeholders as soon as possible. Prototyping and building repeat over and over through iterations until a product is complete and meets customer requirements.
This is ideal for smaller projects with a well-defined objective. The process helps developers make quick adjustments based on frequent feedback from stakeholders. It’s all about creating quick prototypes that can get in front of users for constructive feedback as soon as possible. This feedback is pulled into the user design so that development decisions are based on the direct thoughts and concerns of those who will use the product.
8. DevOps deployment methodology
The DevOps deployment methodology is a combination of Dev (software development) and Ops (information technology operations). Together, they create a set of practices designed to improve communication and collaboration between the departments responsible for developing a product.
It's an ongoing loop of communication between product developers and Ops teams (IT operations.) Like so many agile processes, it relies on continuous feedback to help teams save time, increase customer satisfaction, improve launch speed, and reduce risks.
The steps of DevOps deployment repeat, aiming to increase customer satisfaction with new features, functionality, and improvements. However, this methodology has some drawbacks. Some customers don’t want continuous updates to their systems once they are satisfied with an end product.
Software development made easy
Most software development teams use a combination of methodologies and frameworks to fit their team size, team dynamics, and the type of work being completed. The key is to use an agile methodology and work together to continually improve your systems as you learn and grow.
Easy Agile is dedicated to helping teams work better together with agile. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams deliver better for your customers.
Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.
CompanyMy journey from psychologist to software developer
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.)