The example of adding two numbers is very common in resources on testing for beginners, probably due to its straightforward nature many can remember from maths lessons. The tests go on checking that given two numbers you get their sum in return. Whilst it makes sense in theory - it’s an example people can relate to - this actually gives newcomers the wrong idea about testing from the get go. Although writing a test to cover two digit addition is no more trouble than writing the code itself (there aren’t edge cases), it sends a questionable message: that we should test the functionality of the language itself.

I asked this question of most of my interviewees, and the consensus was that we should know the functionality of the language itself. We should also trust that whoever built it has checked that the functionality works as intended.

How many seasoned developers actually look at the repo for the module they are using? Checking how robust the testing is? Or do you just look at the number of downloads and make a decision based on that?

If you really like the module and would love to use it, but you feel the testing could be better, overall you will make a bigger difference by making a PR with robust tests to the module repo itself, than testing it within your application.

This is one of those questions which has an answer with a "but" in the middle. In general, you should trust that whoever shipped the code did their due diligence and don't bother testing the library methods you're using. There are two caveats here: - if there is a piece of code that is essential to your application (if this code breaks you lose huge amounts of money) you may want to add a token test or two to be sure the method works exactly as you want it to work. - if you're using any of the methods in a way that isn't specified in the manual, even if they are methods native to the language, you may wish to add a test to be sure that your assumption continues to be correct. Before Node.js 11, one could use array.sort((a,b) => a > b) but the usage of lesser and greater than has not been a documented one, and it stopped working in the newer versions! The reason why you shouldn't do hacky implementations is because the things that are documented have been tested by the developer (one hopes), and the rogue implementations, haven't - so you can't rely on your code behaving in a predictable fashion.

One hopes that any breaking changes are announced through the warning messages at build, but that isn't always the case. Even if the change isn't announced, your tests or your build should fail and alert you to this.

This is an interesting one, as the consensus has been that the more popular the module is, there is less interest in stubbing it out for testing purposes. Those who were asked, were quite happy to run lodash in tests, but preferred to stub out less popular modules, as well as those used internally within the organisation. You might wonder why internal modules are treated this way, but the reason is a very logical one: internal code is subject to review only within the organisation and therefore is not subject to the same level of scrutiny as large open source projects. It is also worth noting that some types of modules are very fragile by their nature - for example ones that touch the file system - and thus are better off stubbed.

The testing pyramid is the concept that came up again and again when talking about testing. And although it is a popular concept, it probably should only be followed very loosely. Oftentimes writing integration tests is as quick as writing unit tests. And it may be that it is less important that the things work independently, and more important that together they do this one specific thing. Your oven door can open, and your drawer can open, but can your drawer open when the oven is closed? With integration tests, you cover a large amount of codebase with comparatively little effort. My interviewees agreed, however, that the E2E tests should be used sparingly due to how fragile they are.

Pure functions - ones that given the same input always return the same output - are definitely easy to test and make your code more robust. Unfortunately sometimes it's just not possible to only write your code in pure functions.

An atomic function is a function that does only one thing. Say you want to check if a number is both prime number and a number in a Fibonacci sequence. Using atomic functions means that your main function will call both a isPrime() and isFibonacci() - the logic lives in those atomic functions rather than being part of a main function. Making your functions atomic will help you with testing and figuring out what can go wrong in each step. But as with pure functions, it is not always possible to write functions that are atomic.

Definitely. API calls rely on a number of factors, including (for example) being logged in and being connected to the internet when the tests run. Mocking out the API response will make your tests more robust, because you cut down on the number of the things they depend on. It is very helpful if you don't have access to the API, but you know how the returned data is structured. Mocking the response allows you to write code that you can be confident does what you want it to do. Mocking (as opposed to using Nock), works well if you know the input and output, but you aren't sure what is happening in the middle, for example when working with AWS SDK or with URL encryption.

No. Imagine your function takes an object and returns the same object but with a new key-value pair. For example, it takes a user object (where one of the keys is the date of birth), and returns the same object but with a new key "age". The object you give to the test can be just { dob: '2002-10-12'}, even if in reality this object would have twenty other key-value pairs. And the expectation would only check that the object contains the {age: 18} key-value pair.

Yes, even if it's only one test for each critical path. Yes, they will often break on CI and then work on re-run without changing as much as a space in the code. Sometimes there's a blip in one of the APIs they depend on. Sometimes it's a race condition that fails. They are needed to make sure that a straightforward user journey works. The fragility can also be helpful and expose changes in the APIs and modules you use. In my short time at the FT (5 months at the time of writing), our E2E tests have highlighted a change in our dependencies at least twice. One was when our component library team made an item invisible on the page, and we were using this to find our data for testing. The test suite couldn't see those items, so failed as if they weren't there. The second was one with a much bigger organisation impact, and although this API change was only made in the test environment, it affected not only our tests (which rely on creating fake users in the test environment), but a number of other teams’ pipelines as well. If you encounter race condition errors more than you'd like on CI, there is a big chance your users will also encounter it.

A very strong no. There will be people who will tell you otherwise. There will be services that refuse to work with your code unless the test coverage is above a certain threshold. Enforcing 100% test coverage will make you write tests to meet the coverage requirement rather than help you be confident in how your code works. 100% test coverage often comes with expensive overheads, where a minor change in code may impact a large number of tests which take time to be changed. If that happens every time you change the code, those programmer hours add up. You may also run into situations where you deliberately put in some amount of bloat code and tests for it, just to improve the coverage percentage. 100% test coverage tends to make tests become an overhead and therefore counterproductive.

Snapshot tests are better than nothing, and are useful when you are refactoring code and want to make sure things still look the same. Snapshot tests often fail at being specific - does this massive wall of text match exactly with this other massive wall of text? Oftentimes changing a single word, or a class, means creating another snapshot, but we rarely commit changes word by word, so this approach may hide visual regression discrepancies even though the test is there. Furthermore the user generally cares about the content and not that the website has so many divs and so many buttons.

If they are essential to your business and the other data would not make sense without them (for example data labels), a quick check doesn't hurt. But there's also an argument that given this data is hardcoded, it will always be there if the component renders. Bottom line, if you can check that the values show up as expected without hunting for the exact deep nested comparison, do run a quick check.

No. One of the things that came up again and again, is that the tests should tell you, very specifically, what broke. If you check for a result of, say, a maths equation, giving it a bunch of matchers like is it "truthy" or "falsy", or "not an object" doesn't help you in any way if it breaks. If the answers should always be three, check that the result is three. Don't bother if the result is less than or equal to two, or the result is greater than or equal to four. But if the answers could be anything less than two, the test should be if the result is smaller than two.

Tentative yes. One of the rules of testing is to make sure that the tests are supposed to pinpoint precisely what went wrong. Imagine you have a function buildACar() and this function calls buildFrame(), attachMotor(), attachSeats(), and so on. If your test for buildACar() fails, you will most likely struggle to pinpoint which of the inner functions does not work as intended. But you also want to make sure that the car works as a whole.

This is a tricky one. Imagine you have a function that takes two numbers, between one and ten. Writing a hundred tests seems ridiculous because of the high overhead for change. You get diminishing returns the more tests you write. Also, if the function doesn't work, it will probably break the first test. If your code has two paths, check both. If it has over twenty, aiming to cover between ten and twenty percent of the cases is probably the reasonable thing to do. There might be exceptions - if you're in banking, or the medical field, you may wish to test all the paths to give you a peace of mind.

If your function is difficult to test, it is a sign that it would benefit from being refactored in such a way that it can be tested easily. It is worth your time to refactor the logic so that you can test your code and therefore have confidence that your important function is doing what you want it to do.

Test Driven Development (TDD) is something that is widely spoken about - because it seems like an excellent idea - and yet rarely practiced (in my experience). You can't really do TDD if you don't know what your data looks like - but console logging things as you go so you can do at least a bit of TDD is a valid approach. It does come in useful, however, when writing data transformation functions - it is often quicker to write a test than to reload the page and click what you need to see if your change worked. TDD also relies on being able to figure out the happy and sad paths before you write the code and sometimes this is difficult.

Shout testing is a nickname for a lazy approach of "if I turn off this app and it affects someone, they will come and complain" (rather than asking around if someone is using the app in the first place). I would not do this deliberately because that means you know that there is a functionality you haven't tested and you're letting the user be the guinea pig. If this is about some obscure edge case, that maybe happens due to a race condition only present in certain circumstances, it is reasonable that you were not able to imagine this happening and shout testing is a valid way of exposing the bug. But if you do receive alerts via shout testing, make sure to write the test - you now know the circumstances and the steps to reproduce the bug, or at least what the undesirable behaviour that is occurring is - and patch the bug.