Who is this post for: bootcamp grads who didn’t receive instruction on testing in their course
What does it cover: an overview of the types of testing you should know about, along with links to further resources

Congrats on graduating from your bootcamp! Just when you thought your brain couldn’t get stuffed with any more concepts or ideas, welcome to the wonderful world of TESTING. This blog post should get you started with some fundamentals. Good luck!

Before we dive into testing, there’s a mindset shift you need to make. When you are learning at a bootcamp, you are working at a very small scale. You don’t need to consider things like application load, test performance, pipeline execution time – you just want it to compile and run. But once you get into professional software development, scale is probably the biggest difference: we have over 4000 tests for our backend system alone. Test execution time is something we care about. Once written, an automated test can provide value for years. So part of understanding a good test strategy is understanding the scale and the timeline of an enterprise project. Now on to testing!

What is testing? Testing really means “automated” testing. Manual testing is something we avoid as much as possible because it’s not scalable or reliable (humans make errors). Testing is a critical skill for modern software developers, and most importantly, it’s often the differentiating factor in whether your tech test will pass.

What kinds of testing are there? Broadly speaking, there are 3 main types for you to worry about now. These types are in the testing pyramid below:

Pyramid of Automated Tests

Unit tests are the foundation layer. This is where you practice the famous test-driven development (TDD). We like unit tests because they are fast to run, don’t require complicated setup, drive good code practices, and give quick feedback to the developer. Not sure what to test? Start with normal, boundary, invalid and extreme testing.
Resources:
The Test Pyramid
TDD By Example by Kent Beck
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
Secure by Design by all the Dans. This book is highly readable and will help you with design and testing.

Integration tests (also called service tests) test the communication between different parts. You don’t want to check details of logic here because these tests have a more complicated setup and are slower to run.
Resources
– Integrated Tests Are A Scam

Acceptance tests (also called end-to-end or E2E) tests for web apps usually through a browser (sometimes headlessly, sometimes not). They are attractive because you can see the interaction, and they are unattractive because they are SLOW and notoriously unreliable – if your network speed tanks, the test could fail because it looks for a button that hasn’t turned up. Basically you want to avoid these as much as possible, but they do have value.
Resources
Cypress testing framework

Bonus test types
As a junior developer, you probably won’t need to worry about these types of tests, but it’s good to know!

Load testing: how does your application behave when stressed, such as receiving too many requests at once or a request with a payload that’s too large to handle.
Resources
https://www.guru99.com/performance-testing.html

Penetration testing: this is normally done by a 3rd party security expert. They are looking for vulnerabilities in your application.

Image by Niek Verlaan from Pixabay

You’re a junior developer, you have your first tech test, and you want to impress the potential employer. Here’s how.

README
This is the first thing I look at. Your README should have:
– the specs (what the problem is you’re trying to solve)
– instructions to run the code (assume I will clone the repo – then what should I do?)
– any explanations you want to give for why you did things
– further refinements / features you would add given more time

Git Usage
While there have been other version control systems, git is industry standard now and I’d expect to see it on any tech test.

.gitignore
Even if it’s blank (and it won’t be if you are using npm packages or an IDE), it shows you’ve thought about what needs to be committed to a git repo and what doesn’t.

Commit History
This is a more controversial one, as looking at my own history, I see the occasional gem such as “3312: make code less manky”, and I’d hate for people to think every commit message has to be a work of art. However, a good commit history can show your thought process and your collaborative skills – what happens when you win the lottery and I have to take over your project? First thing I do is look at the commit history as a summary of what you’ve done and how you approached the project.

Code Analysis
I want to understand how you’ve thought about the code. In particular, I want to see:
– code coverage (SimpleCov for Ruby, for JavaScript use Jest’s built-in –coverage flag or Istanbul/nyc)
– linter (Rubocop for Ruby, eslint for JavaScript)

Testing
The first part of the code I look at is your tests. Poor test coverage is an immediate cause for rejection. In addition to 95% or higher line coverage (there is a law of diminishing returns so don’t worry about getting it to 100%), I also want to see:
– boundary test cases: if you’re working with numbers, have you tested one above and one below your highest/lowest number? Or if working with text, have you considered whitespace before and after the word/characters?
– error handling: particularly in dynamically typed languages such as JavaScript and Ruby, what happens if the calling code gives the wrong type of input, or no input, or too much input? E.g., if you have a function to multiply two numbers, what if one of the inputs is a string? (Side note, this is why I prefer statically typed languages, which specify a type and will fail to compile if the type is wrong!)

And finally, do yourself a favour and learn TDD. It will solve most of your test and code problems. Kent Beck’s book is a great place to start – it’s in Java, but you can translate as you go to the object-oriented language of your choice.

Code
The last thing I look at is for your code. And the first thing I look at is whether you follow Sandi Metz’s Rules for Developers. While they might not always be relevant in production, real-life code (although they often are!), there’s generally no reason that in the artificial environment of a tech test you can’t follow these rules. And in fact, you should also apply these rules to your test code.

Then, when I’m looking at your code, I’m thinking, “If there is a bug in this code on Friday at 4pm, will I be able to understand clearly what’s going on or will I be tearing my hear out?” In other words, does it communicate its intention clearly? Code does this by:
– short methods that do one thing only
– methods and variables that are named according to what they do (if you have a method that is called getResponseFromServerAndComputeFunction, that method is too long and doing too many things)

Immediate Rejection List
The following will guarantee you an immediate rejection from a lot of reviewers, myself included:
– no README. We are busy and don’t want to use a crystal ball to figure out what we’re supposed to do
– no tests or poor test coverage
– not using git or all code in a single commit

And finally, I want to clarify that this is my personal list, heavily informed by my training at Makers, coding best practices, and my experience as a professional developer. Not everyone will have this same list and I also try to approach each candidate with an understanding of their individual circumstances.

Good luck and let me know what you think in the comments!

In a recent blog post, I started thinking about software as performance art, linking it back to my life as a violinist. I realised that, although I felt very definitely that software and violin are both performance arts, I couldn’t really define performance, art, or performance art. So I’m going to start by thinking about what art is. (Note that this is a deliberately self-reflective post: it’s what art is to me, not what others have thought and written about it.)

I find it’s easier to think in concrete examples rather than abstractions – so when I think of art, the first words that come to mind are sculpture, music, drawing, light. These words have an inherent sensuality: when I think of sculpture, I imagine a marble statue, but mainly by touching it and feeling the cool, smooth, slightly textured surface. When I think of music, I think of my violin: dark honey-coloured wood with mesmerising patterns that I could stare at for hours, and the scent of a luthier’s workshop. Drawing: I think of the feel of a pencil on rough paper, creating a slight ridge in the paper and the vibrations transmitting up my arm. Light: the shaft of light through a window hitting the marble sculpture, or even more heavenly, the filtering of sunlight through green leaves. There is nothing more blissful than this.

So art is physicality, sensuality – a way of experiencing the world that is deeply linked to the physicality of my body.

I haven’t said much of smell and taste, which to me are the most intimate and evocative of senses. Maybe another time – my experience of smell and taste are too personal for me to share.

How does art come to be? Is it deliberately created? By humans? Is a field of bluebells art, or is it nature? I would have said art is created by humans, but then the sunlight filtering through the green leaves…is that nature or art? Does it matter?

I think I will be broad and say that the sunlight in the green leaves is art.

And maybe this a characteristic of art: it expands and deepens our experience.

I leave you with this suggestion: find something you have never smelled and inhale its scent deeply.

Today in BRYTER’s Q4 2020 Inspiration Day, I ran a session entitled “Software as Performance Art”. It was my first tentative toward steps toward finding underlying harmony between my performances as a violinist and my career as a software developer.

I know performance is an essential part of my identity and the way I create community for myself. But I’m not sure I can even define performance – I am only confident stating its specific characteristics in the particular area of Western classical music: I walk on stage, sometimes alone but usually with friends, play music, receive applause, leave.

I think I know what art is – but again, I’m only confident in listing specific incarnations (music, sculpture etc).

I’m really not too sure what performance art even is! But did that stop me from asking if software can be performance art? Not at all, luckily.

Of course, what is software? And do I care about software or code? Does code exist only as a mental abstraction when the server is not currently running? Does it have physicality? How can you perceive it with your senses? Does it have emotion?

I think I am tentatively working toward an understanding of the code itself (including tests!), unrelated to a UI, as a form of performance art. Art, because it is creative and expressive (whether it should be beautiful is another question!). Performance, because it is not written to be languished in a museum but rather worked on, improved, enhanced.

We’ll see where I go with this!

In my spare time, I help classically-trained musicians like me transition to software developers. One of them recently asked me, “I don’t have £8k to spend on a bootcamp. Can I just teach myself to code?” Here’s my answer (disclaimer – I’m a bootcamp grad so this is not first-hand experience).

Yes, you can learn to be a developer without going to a bootcamp (or getting a CS degree). I know this, because people have done it. So let’s discuss what a bootcamp does, and how you can replicate that yourself.

A good bootcamp should give you two things:
1. A structured learning environment
2. A foot in the door at job interviews

Let’s talk about the structured learning environment. Writing software professionally generally involves working as part of a team. This almost always means using git, creating pull requests, reviewing code, writing documentation, and can also mean working in a sprint schedule, daily standups, and pair programming.

Because you do a bootcamp with other people, you have a built-in team. Different bootcamps do this in different ways – at Makers we paired daily and then had group projects in later weeks. This meant that we learned to use these critical software skills like git and were comfortable especially with pull requests and reviews.

The structured part is more obvious – you pay money to someone to create structure for you. Can you create the structure on your own? That depends on your own motivation and discipline.

I’m considering the course content as part of the “structured learning environment” and I won’t delve deeply into it here. But figuring out what to learn (as opposed to how and where) is its own challenge!

So let’s talk about job interviews. Bootcamps usually have relationships with companies and can get you past initial screening. This (in my opinion) is one of the most important things about a bootcamp – what sort of job can they land you afterward?

The good news is that you can network on your own as a developer by attending meetups, communities such as CodeBar, joining Slack groups devoted to topics you’re interested in and getting active on Twitter. (And in fact if you’re attending a bootcamp, you should do this anyway.)

And once you’ve learned a bit of code, probably the best way to build your portfolio, experience, and network all at once, is to contribute to open source projects. Find a project you’re passionate about, check that they have a good code of conduct, and dive in!

Good luck with your code journey 🙂