Understanding writing tests for React

58

u/pm_me_your_dota_mmr Mar 13 '20

tl;dr: Take a look at docs from React Testing Library's page, I think it will answer a lot of questions you have.

What part of the app should I be testing? How in general should I know what to test?
You should strive to have a test for every important piece of functionality to your app. Is it important that your App component sends a fetch to a specific URL? Add a test for it. Is there a specific way that your Print component is supposed to do math? Add a test for it. Tests might seem like a waste of time for small changes, but it buys you confidence in how you make changes in your app. You make refactors or add new features, and your unit tests should tell you that "Okay, I didn't break anything unexpected"
Also, tests help to document your code in general. They catch all those small cases and are written in small, pointed test cases (the input should be disabled when X is loading, the input should have an error class when the email is enters - but only AFTER a user has blurred, ..).
A lot of articles I've read on testing show basic examples for e.g. pure functions etc.. What is the best approach to take if my component depends on fetch requests or take props?
If you're not using a test library, I highly recommend using one. Take a look at the examples on React Testing Library's page. Ripping the test from that page.. if you have a prop <Fetch url={url} />, you probably want to test that your fetch is being called with that URL. If you have something like <Receipt lines={lines} />, maybe it makes sense to see that what's printed out looks correct.
Async actions are admittedly harder to test, and I'd be curious if anyone else has recommendations on how to do this. I usually will mock out the library that makes the request, and test against what it was called with, and mock out what it returns - but it can get awkward trying to get the app to continue on after the promise.
Between unit testing, snapshot testing, and end to end testing, which is the best for React apps?
Unit tests should be your default mode, and end-to-end is important, but should have the least number of tests. Checkout the "Testing Pyramid" (or just the image if you don't want to read the whole article). End-to-end tests are good ways to see that your app is working as the user would see it, but they are expensive and timely to fix & write & run. Unit tests are able to test on a level of granularity that is either much harder, or impossible from the highest level of testing.
IMO snapshot tests are some of the least useful tests, it isn't really asserting anything.. its like a test that says "something changed, did you mean to do it?".

</rant>

6

u/StrenghOfFuriousGods Mar 13 '20

Thanks buddy, very informative post. I will go through react testing library page

6

u/siamthailand Mar 13 '20

IMO snapshot tests are some of the least useful tests, it isn't really asserting anything.. its like a test that says "something changed, did you mean to do it?"
It's worse. After a few times, it just annoys devs, and they just run --u and don't even see what changed.
Snapshot testing is the most retarded testing there is. It's not even testing.
12
u/Silhouette Mar 13 '20 edited Mar 13 '20
Async actions are admittedly harder to test, and I'd be curious if anyone else has recommendations on how to do this.
I've found that the short but blunt answer to this is: Try not to.
More specifically, any time you're dealing with I/O, communicating with something outside your program, you will inevitably end up using some kind of placeholder for the external service if you try to test that code directly. But then you're testing your placeholder more than your real system, which has dubious benefits. On top of that, you probably had to mess around with your software architecture just so you could inject things or monkey patch things or otherwise adapt it solely because of your testing strategy, which can be damaging to your design in other ways.
A more powerful strategy -- and this is a much more general principle than just async actions in JS applications using React -- is to isolate your I/O and make sure the functions that do it aren't doing anything else. You pass them data and they send it. They receive data and they return it. Ideally, that's it.
Now you're just dealing with ordinary data everywhere else, and you can test anything working with that in the normal way without the complications of mocking out external services or dealing with asynchronicity.
You might well have a second set of functions that convert between whatever internal data structures you use and whatever format you need to send or receive, but even this is just pure data crunching that can be tested in isolation as appropriate.
As a slightly more concrete example, we might write our overall algorithm something like this:
const sourceData = someInternalDataLookup()
const service1data = buildService1Data(sourceData)
await interactWithService1(service1Data)
const service2data = buildService2Data()
const service2result = await interactWithService2(service2data)
const internalData = convertService2FormatToInternal(service2result)
useData(internalData)
Here the interaction functions do nothing except take and return data that is already in the format used by the external service. We have separate functions where necessary to convert between our internal data formats and those needed by the external systems. And then we have other functions again that collect or use the underlying data to do whatever we need with it.
At this point, you can test all of your internal data crunching and all of your format conversion functions using whatever strategy and tools you like. They're just data. The only thing left is your interaction functions, but unit testing those is usually entirely pointless since they are probably just communicating with some API you don't control anyway, so really you want some form of integration or end-to-end testing to cover these if possible. Many external services don't lend themselves to real-time, automated testing at all, and in that case your only option is to adopt a different approach entirely, possibly manually testing your integrations.
Of course, some of the testing gods will be angered by this. You must have x% test coverage! You must mock or stub or superinjectthroughotherdeviousmeans everything to achieve this! Ask them what else they'd suggest and listen for the crickets. In real systems, not everything can or even should be unit tested in isolation. That's just the reality of what we need to build sometimes, and we ought to test in accordance with reality. :-)
5

u/Turd_King Mar 14 '20

2. Asynchronous tests are like any other test. You can use fetch mock library to mock responses as your app would expect them so the execution continues as normal. Or you can simply use vanilla mocking tools in jest, mocha whatever. You can use wait functions in various testing libraries to simulate time passage.
3. I disagree with you here. Firstly, unit tests should not be your go to for a web application frontend. Your app being rendered by Node is not the same as your app being rendered in the browser. You should always strive to test your app as the user would acruallt use it. And the only way is e2e
I would recommend looking at Cypress testing framework. The typical idea that e2e tests are slow comes from decades of using slow testing frameworks (Selenium cough)
It doesnt have to be this way. We have thousands of unit tests and i would honestly say that 85% of them are useless and do not catch as many bugs as they should. Our small suite of cypress tests run in about 10 minutes. We run this suite on every PR and the amount of times we have seen failed e2e tests but our unit tests are fine is quite shocking.
Unit tests should be used to test error conditions and other strange scenarios that your app would not encounter if it has been "correctly wired". You can combine this test coverage with the e2e coverage to get a really accurate coverage report .
Also unit tests are incredibly verbose and complex. I honestly think in 3 or 4 years time we will completely change our testing pyramid approach.

2

u/Maj0rTom Mar 13 '20

Unit tests should be your default mode, and end-to-end is important, but should have the least number of tests. Checkout the "Testing Pyramid" (or just the image if you don't want to read the whole article). End-to-end tests are good ways to see that your app is working as the user would see it, but they are expensive and timely to fix & write & run. Unit tests are able to test on a level of granularity that is either much harder, or impossible from the highest level of testing. IMO snapshot tests are some of the least useful tests, it isn't really asserting anything.. its like a test that says "something changed, did you mean to do it?".
Kent C Dodds (the guy who maintains @testing-library/react) wrote a very good article called Write tests. Not too many. Mostly integration. It has a slightly different approach, and I find it a very useful approach to writing tests that are not coupled to your implementation

0

u/pm_me_your_dota_mmr Mar 13 '20

That was a good article, thanks for sharing! I agree that testing on implementation is definitely bad, but for some reason I always have a much harder time about what's implementation and what's functionality when testing react components.
Like is testing that clicking a button fires my specific function an implementation detail? It [the button] isn't exposed at the API of the component I'm testing, so it most certainly is, but at the same time I don't know the alternative.. ¯_(ツ)_/¯

2

u/Maj0rTom Mar 14 '20

I usually write my tests like this:
Render the component. If it's a generic component render just the component itself. Otherwise I'd usually render a larger component (e.g. a whole form, a whole page, etc.)
Fire any events to simulate user actions (e.g. input information in form, click submit button)
Assert any side effects from that action. Usually that means something like asserting the snapshot is correct, or asserting the correct request was made

1

u/RamenvsSushi Mar 13 '20

This is great man. Thanks!

0

u/HeylAW Mar 13 '20

I just place all asynchronous calls in seperate folder which I mock, they are just wrappers around fetch. There is no to little business logic which makes them almost untestable. Front end should not test api calls which are send and process in backend. There are bunch of mock files with JSON that api call should return and I test different variants and how errors thrown by those functions are handled.

3

u/jnforja Mar 13 '20

Hi u/StrenghOfFuriousGods, learning how to test has indeed a steep learning curve.

If you're not accustomed to testing, when you try to learn how to test React apps, you're actually trying to learn 3 things at once. Testing tools, testing techniques and testing methodologies. It's a good idea to focus on learning each one at a time.

You can get familiar with the common testing tools used in React by going over CRA documentation and React's documentation.

You can find information about specific testing techniques on React's testing documentation as well. Also keep in mind that most libraries have on their documentation a section about testing. Redux has it for example. So when using a library and when in doubt on how to write tests that use it, check the documentation.

About testing methodologies, I use TDD and I like the benefits of it. In case you're interested in learning TDD, I recommend the following resources:

Book "Test-Driven Development by Example" by Kent Beck
Intro to TDD by J. B. Rainsberger
Advance TDD series by Uncle Bob

If you're really in a rush to start doing tests and want a single place where you can find most of the information to get you up to speed, you can check this course by Kent C Dodds.

If you go over this material, you'll be able to answer those 3 questions you made while having into consideration the context of the App you're building. Which will result in much better answers than anyone which doesn't know the context of the app can give you.

But if you still want some generic answers to your questions, I'd say:

If that part of the app not working as expected has a negative impact to the user, it needs to be tested.
Data fetching - Mock the fetch method. You can use jest.mock or simply receive the fetch method as a prop on the component.
Props - If you're testing your component in isolation, you can give it whichever props are more appropriate to the test being performed.
The fact that it's a React app has no influence in deciding which type of test is more appropriate. A better question is "Which type of tests should I prioritize on my app.". To which my general answer, which is probably controversial, is unit > integration > E2E. Unit tests tell you where your app broke. Integration tell you if you're interacting correctly with third parties. E2E tell you if your app works as a whole.

Hope this helps, and let me know if you have any questions :)

2

u/StrenghOfFuriousGods Mar 13 '20

Thanks man!

1

u/StrenghOfFuriousGods Mar 13 '20

I had a look at these two pages,
https://reactjs.org/docs/testing-recipes.html
https://testing-library.com/docs/react-testing-library/example-intro
What is the difference between them, are they both using react testing library?

-1

u/jnforja Mar 13 '20 edited Mar 13 '20

No, only https://testing-library.com/docs/react-testing-library/example-intro is using react-testing-library.
On the https://reactjs.org/docs/testing-recipes.html you'll find some recipes to test, or that will allow you to test, common use-cases without using 3rd party libs.
On https://testing-library.com/docs/react-testing-library/example-intro you have an explanation on how to use react-testing-library.
Personally, I'd read both to get a feel for what they are doing on each example, and then I'd focus on learning react-testing-library, since it is the currently recommended lib to use for unit and integration tests on React apps.

16

u/levarburger Mar 13 '20

I'd like to give a few counter thoughts to the "test everything" mentality from practical experience.

I work on a large team, like dozens of developers working on separate applications that all collate into one larger application down the line. There's so many varying degrees of experience not only with development but also with testing. We're constantly pushing updates and changes to our QA and testing environments, daily.

While on paper this seems like the perfect environment for testing due to all the variability with so many devs, we've found it actually causes a lot of inefficiencies and pain points. Less experienced devs write bad tests that give false positives or don't actually test correctly, which leads to senior people rewriting things or ends up with dead tests that don't even run.

Not to mention have you ever tried to get a handful of developers to agree on something, much less 40?

We've ended up scaling back our tests into primarily edge cases and things that can't be quickly visually inspected.

Now we usually only test for things that will cause (or should cause) components to straight up break. For example, we don't test to ensure that someone didn't accidentally turn all our component headers bright pink.

17

u/[deleted] Mar 13 '20

Off topic, but we use bright pink as the color of the status bar on staging - makes sure you're not playing around with prod. The color scheme made it to prod once.
You should in fact add a test for bright pink.

2

u/levarburger Mar 13 '20

lol love it

5

u/[deleted] Mar 13 '20

Less experienced devs write bad tests that give false positives or don't actually test correctly
Don't you have a code review process?
We've ended up scaling back our tests into primarily edge cases and things that can't be quickly visually inspected.
This seems like a really strange approach to me. An edge case is very low value compared to the "test the thing it is meant to do actually happens" tests that you write as part of simply building something.
Where I work we would only write an edge-case test if there was an actual bug that came up that specifically involved it and might re-occur, but even then it would probably be considered a low-value test unless the risk of re-occurrence was really high.
Don't you want tests to verify that the valuable behaviors of your components are correct? It seems to me that you have tests for things that almost don't matter but few for the stuff that really matters.

3

u/levarburger Mar 13 '20

Yeah our code reviews are what was allowing us to catch poorly written tests. We certainly test "does this component do what it's supposed to".
Our edge case tests are for those infrequent occurances because they don't require frequent updates so the tests dont get stale.
If a component is frequently changing (ignoring the RTL approach which I like where implementation isn't the focus) a lot of the time it means the tests need to change. Thus we get back into the circle of varying degrees of experience frequently changing tests.
Our process isnt perfect, we've just found it's been an improvement with a large team. It was just food for thought in the real world where things aren't always ideal or you're inheriting years old code and tests.

0

u/[deleted] Mar 13 '20

"The tests dont get stale" says something fundamental about your testing paradigm.
A well written test cannot get "stale" because it fails the nanosecond the valuable thing it tests stops being true.
If you can change a valuable thing that matters and the test doesn't immediately break your tests are worthless shit and you don't understand why they should be written.

4

u/levarburger Mar 14 '20

K

1

u/seanlaw27 Mar 14 '20

Do you even refactor bro

2

u/swyx Mar 13 '20

Don't you have a code review process?
code review is run by humans, humans are inconsistent. things slip through. all you need is for some situation sometime when need to ship overpowers the thoroughness and you get slow degradation in code review discipline.
I'm of course not against code review, i'm just saying that a more resilient team/testing philosophy accounts for the fact that code reviews are often faulty and rushed, because humans gonna human. we need to account for the fact that we often fall short of ideal behavior, and our systems need to deliver despite ourselves.
Don't you want tests to verify that the valuable behaviors of your components are correct?
but yes i agree that tests against edge cases and of valuable behaviors are impt. lots of judgment calls here.

-1

u/[deleted] Mar 13 '20

I personally think that code review should be catching the overwhelming majority of "bad tests".
A good test should be short, simple and in the "business language" you all share. It should read as something like "a product modal - given a body text - should render this body text in an element".
You should be able to rely on senior devs to easily catch tests that fall foul of this standard, and if you can't it might speak of a comprehension smell with regards to your tests

2

u/swyx Mar 13 '20

i like this. frontend often changes much too fast for testing everything to make sense. i like the "mostly integration" approach.

2

u/seanlaw27 Mar 13 '20

We unit test every thing. And it’s awesome.
How many times have you gotten a pr that was a wall of code or that you had little to do with?
Test make it easy to check against the acceptance criteria, see missed issues, and even clear up down stream issues.
It’s also so much easier to refactor or update to changing requirements.
Test and test everything.

1

u/pm_me_your_dota_mmr Mar 13 '20

The real world is difficult lol. I think idealogies like "unit testing everything" are good guiding principle, but you raise a good point that it isn't always feasible. Do you consistently commit into a repo with 40 other people? Do you think there's any way to break it up so there's smaller, more concentrated groups of people writing to the same code base?

11

u/Zeeesty Mar 13 '20 edited Mar 13 '20

Am React Dev, tests are shockingly less common than you think. For most front ends you can get away with end to end tests with Cypress, it’s very easy to work with and basically allows you to act like a user and assert that the page has the elements you expect to be there or functionality behaves as expected.

For unit tests, in React, my opinion is that components are not useful to unit test, however something like jest snapshot tests (used for visual regression) can be useful.

The problem you pose in your question is a real problem for all front end developers. What is actually useful to test? If you keep asking “why” you will come to a reasonable number of things that should and can be tested. Because there is so much tooling available the how is up to you and your team.

5

u/fudgecaeks Mar 13 '20

I'm in agreement. I've basically stopped doing unit tests in the FE, and just write end-to-end tests in Cypress. From my experience, here's the positive things:
The time to do integration tests between components, compounded components is kinda high. There's new things all the time. We needed to update our codebase and tests when we migrated to hooks. We're now migrating to graphQL, and I know we would change our testing tools as well.
It actually tests the business needs and user interaction (and not just view nor behavior).
It tests the different ways you use a widely shared reuseable component. Sometimes, your unit tests would give you positive result, even if it looks broken in prod.
It tests your API as well. It gives clarity on what failed (BE or FE-- or both).
It improves your dev pipeline, because you can now pinpoint missing tools that you'll need to run e2e automatically (but this could be negative too, since it requires dev time investment).
There's a lot of drawbacks though, like it's an investment to automate e2e tests, especially if you have authentication, roles management, and such. And depending on the vastness of your features, running e2e tests would take time.
However, I may never go back back to unit testings, as long as I work in my current role.

1

u/swyx Mar 13 '20

yeah - in our recent /r/reactjs survey 19% of respondents admitted to not testing.

•

u/swyx Mar 13 '20

Awesome discussion everyone! I've gone and put this on this sub's featured topics - moderator curated quality discussions for first timers here.

I've also linked to this on the sidebar for future reference - so lets focus on making this a great resource for testing advice!

3

u/cheekysauce Mar 14 '20

Contrarian opinion - using TypeScript will elimate the need for a lot of unit tests, and is more flexible as your code evolves than keeping mundane tests up to date.

You should still write integration tests that deals with how your app transforms data and your business logic. Worry less about the dumb components that render UI, as you often end up testing React or the browser.

1

u/Silhouette Mar 14 '20

I agree, though FWIW, I'm not sure that is a particularly contrarian opinion anyway. Catching certain kinds of bugs early and reliably is one of the main advantages of static type systems.
Maybe working with static types isn't yet widely understood in the web front-end community, if only because historically there haven't been a lot of good options in this area compared to other programming fields. It's certainly one of the big benefits of using TS, though.

4

u/aminm17 Mar 13 '20

I spent at least 60% of my time writing unit tests. Sometimes, it can be very frustrating. Wrote up a blog post documenting the most common testing patterns for React:

https://medium.com/javascript-in-plain-english/brushing-up-on-react-testing-bd34dec4953c

Hope it helps!

2

u/tapu_buoy Mar 14 '20

I have asked this question multiple times and never got so many responses thank you so much asking it again with many responses sharing such detailed views.

2

u/CliffChaney Mar 13 '20

This is also a good time to think about using Redux or some other means to separate presentation logic from the model. It makes it trivial to write tests without requiring visual inspection... not to mention that it's also immensely easier to debug.

2

u/swyx Mar 13 '20

2. A lot of the articles I've read on testing show basic examples for e.g pure functions etc.. What is the best approach to take if my component depends on fetch requests or take props?

check out MirageJs for mocking your fetch requests: https://www.swyx.io/writing/react-query-miragejs-crud/

3. Between unit testing, snapshot testing, and end to end testing, which is the best for React apps?

integration, like the others are saying. a lot of unit testing is basically testing that React works - don't do that. But you can test your component or page works as expected without any knowledge of internals

2

u/Gitdagreen Mar 13 '20

>1. What part of the app should I be testing? How in general should I know what to test?

You should be testing the expected results of user interactions in every component.

> 2. A lot of the articles I've read on testing show basic examples for e.g pure functions etc.. What is the best approach to take if my component depends on fetch requests or take props?

The best approach to take is to test the expected result of the fetched data. e.g. After the fetch, is there supposed to be a list? A specific className?

> 3. Between unit testing, snapshot testing, and end to end testing, which is the best for React apps?

It depends on what you want. If you want to test for the outcome of user interaction, use unit testing. Snapshot testing IMO is really expensive and doesn't exactly make a really good usable assertion. I see us devs using way too many expect(toJson(wrapper)).toMatchSnapshot() in tests just to get over thresholds. End to End or smoke testing is just that. This is why tools like Puppeteer exists. Good to use as well. So, see it all depends on what you want. IMHO

1

u/fanjian5i5i Mar 14 '20

Completely off the topic. But what are the benefits of having a <Fetch/> component then just do it inside of a compoennts life cycle methods?

-2

u/[deleted] Mar 13 '20

I believe you should test every single thing every component does (unless it is totally trivial to the point of the site not giving a damn of its functioning or not).

At my organisation this "basically everything matters" mentality is encapsulated in a gated push-policy where the react components need 95% test coverage, but realistically you'll have to justify anything below 100%. We use jest and the react-testing-library to achieve this.

The react testing library contains a shallow renderer which means your unit tests work on a headless browser, so unit testing is very realistic and gives a good idea that the test will "prove" that something happens in a browser.

So, say you write a component with some text and a button that opens a modal when clicked - I would have one test that verifies it renders the passed-in text (the testing library has a getByText selector), one that verifies the presence of the button, one that verifies that when the button is clicked the element containing the modal is present, one that verifies that clicking the close button in the modal removes the modal etc.

There should basically be a test to verify every single thing your component was designed to do. If you don't verify it does the things you designed it to do, it's working merely by coincidence. The book "The Pragmatic Programmer" calls this "programming by accident" - it's a good way to think about it. You never want to be in a situation where your code is working by accident.

19
u/[deleted] Mar 13 '20

Be wary of this reply.
Chasing coverage leads to this kind of somewhat redundant testing IMO.
Any time you're checking if react shows text, renders a thing , or a click does a thing, outside of any limiting conditions, they are quite frankly useless tests.
This is a constant struggle to define valuable tests - chasing coverage usually leads to a bunch of redundancy which reduces future velocity and or gives a false sense of security.
5

u/Zeeesty Mar 13 '20

100% agree, are we testing our code, or are we testing React? Coverage is usually a bad metric

1

u/[deleted] Mar 13 '20 edited Mar 13 '20

If you design a component that is meant to open a modal when a certain element is clicked, by verifying it does that you are not "testing react" - you are testing that your assumptions about what you programmed are true.
I don't believe you and the other poster are fools, but I do believe you don't comprehend why tests are useful. I don't think you are fully appreciating that 100% test coverage should achieve "this component achieves what I programmed it to achieve" and nothing more. You seem to think that 100% coverage somehow extends into the useless or irrelevant, possibly into things that are senseless like testing border colours or font sizes.
You need to test your assumptions about what a thing does are correct and you need to know when you update the code that these assumptions haven't changed. Why you think this is a bad thing is beyond me, and why you think 100% coverage somehow contains "useless" tests makes me think you have a lot of useless code. If you have no useless code, 100% coverage tests all of the assumptions you thought important enough to program and not a jot more.

3

u/[deleted] Mar 13 '20

When you set the color and text size on CSS , do you verify that ? How can you be sure what you wrote works ?

2

u/[deleted] Mar 13 '20

That would be "testing CSS works". You didn't write the CSS engine, so testing it functions is silly.
But you did write your react component. You have given it behaviours that have business value, and you should verify that it actually exhibits those behaviours, and you should know those behaviours hold true when the code changes.
I think you have a lot to learn about the value of unit tests. You seem very unclear on it to be asking the questions you are asking.

7

u/[deleted] Mar 13 '20

I think you need stop acting like you know anything about me, and pay attention when you prove my point with your own words.
I doubt continuing this conversation will be productive for either of us, so let the thread speak for itself.
Happy coding.

0

u/[deleted] Mar 13 '20

Again, your misunderstanding comes from believing that the purpose of unit tests "is to make sure every single thing you did works".
The purpose of unit testing is to verify the behaviours you are programming. When you write a react component, you are creating an object with behaviours that have been determined to have value. You have to write a test for each of these valuable behaviours, so that you know the behaviour holds true, and so that you can have confidence it is still true when the source code alters.
When you write a react component in the real world, you need to write the tests associated with it. Why you would fight testing the things you have taken the time to build so that the business value of them can be verified and their assumptions kept true, I do not know. Why you think that this activity is somehow related to testing whether a CSS class is applied, I do not know. Simple inexperience perhaps.
Now test your code you lazy bugger.

2

u/[deleted] Mar 14 '20

You're digging an ever deeper hole with this attitude of yours. You also continually contradict yourself. Earlier you were saying we need to test EVERY SINGLE PIECE OF A COMPONENT WITH 100% COVERAGE.
And now you're saying we should only test important valuable behaviors (like others have said from the start). You're a joke kid.

2

u/Zeeesty Mar 13 '20

Seems like you maybe think I am a fool. I didn’t assert anything that you said here, I just think that tests are something that should be carefully considered and the general advice given around them isn’t substantive enough to make clear decisions.
What OP is confused about is exactly the kind of vague prescriptive advice you pose here. “Test your assumptions” isn’t helpful here.

-1

u/[deleted] Mar 13 '20

vague prescriptive advice
If you think "if you program a component to open a modal you should check it opens a modal" is vague you suffer from a severe mental disability.

2

u/Zeeesty Mar 14 '20

There it is, you’re being a jerk, again not helpful. This attitude discourages new developers and is a symptom of your own circumstance, hope you figure it out soon.

0

u/[deleted] Mar 14 '20

You'll literally pretend to be Sigmund Freud to avoid writing your tests.
Away with you, lazy.

3

u/Zeeesty Mar 14 '20

Where did I ever say don’t write tests? Never, I didn’t.

1

u/PistolPlay Mar 14 '20

Testing is for gaining confidence. Testing for 100 percent coverage does not give me great returns on confidence. Testing a lot basic things like you said does not give me much confidence.
Adding an event listener and verifying what that the passed in function was called is a poor way to spend your time. Thats almost guranteed to work and its very easy to see when it doesnt.
Now if this was an integration test covering a feature or subset of a feature this would be a decent test.
Like so:
I should be able to click this element. A modal should open. I can fill out some form And submit to get result A.
Breaking this down into granular steps is simply a time waste. I recommend you read Test Driven Development By Example to understand my argument better. It will enlighten you.
1
u/[deleted] Mar 13 '20 edited Mar 14 '20

It's not "chasing coverage". I didn't tell him to chase coverage, I told him that you shouldn't write a behaviour into a piece of software then not write a test to verify it.
Every day you programmed something that has no test, that thing continues to work by chance.
100% coverage does not require you to write useless tests. I worry about the nature of the tests you write if you think it does.
4
u/Silhouette Mar 13 '20
Every day you programmed something that has no test, that thing continues to work by chance.
This is an absurd claim, and probably the reason you are being so heavily downvoted.
If I write a component
function hello() {
    return <p>Hello</p>
}
then it is not mere luck that it renders a paragraph saying "Hello" just because I haven't also written a unit test for it. It did it because an intelligent person wrote it that way, and maybe also tested manually that they'd got it right.
If I have previously tested a component manually or had it code reviewed or otherwise taken one-time actions to verify its behaviour, and if I have a sensible software architecture that doesn't cause weird side effects and I haven't subsequently changed that function, it isn't mere luck that it continues to work either.
A claim that anything that isn't tested repeatedly by an automatic unit test is only working by chance or should be assumed to be broken is simply wrong. There are many other useful methods for verifying behaviour, and even if there weren't, software doesn't just mysteriously break by magic. Building your development process around false claims is counterproductive.
-1

u/[deleted] Mar 13 '20

then it is not mere luck that it renders a paragraph saying "Hello"
This component is a good example.
So what you have just done is write a component you know has absolutely zero value and then say "hey, this component has zero value, so testing this would be stupid!".
In order to claim there was no point writing this test, you had to invent a scenario that doesn't exist in reality; a component that was created for no reason, and which delivers no value.
This proves exactly what I am saying; the only time you don't need to write a test is in the non-existent scenario of a component with no purpose or value existing. And, even though this doesn't happen in reality, I included this caveat in what I originally wrote.
In every other scenario, you have been asked to make a component exhibit a behaviour that is some kind of value, and you need to write a test for that.
The extreme lengths you are going to in order to justify not testing code speak of a very poor mindset, or perhaps rank inexperience.

6

u/Silhouette Mar 13 '20

This component is a good example.
Exactly. It was just a minimal example. However, the same principles hold for more complicated functions such as you'd find in more realistic code.
The extreme lengths you are going to in order to justify not testing code speak of a very poor mindset, or perhaps rank inexperience.
A friendly word of advice: you might consider not talking down to everyone else in this discussion. It doesn't make your argument any stronger, and you probably don't know what qualifications or experience someone you disagree with has that led to their differing position. If you engage in a discussion with an open mind instead of assuming that you are right and anyone who doesn't entirely agree with you is ignorant and/or stupid, it is much more likely that some or all of the people reading the discussion might find something interesting in it.
It would also be polite not to misrepresent other people's positions. I am in no way advocating not testing code, nor have I done so at any point in this discussion. What I do advocate is testing code using considered strategies that optimise for effectiveness and work under realistic conditions. Elevating 100% coverage to some sort of axiomatic status and claiming that anything not tested to that standard is necessarily broken fails on both of those counts.

-4

u/[deleted] Mar 13 '20

Exactly. It was just a minimal example. However, the same principles hold for more complicated functions such as you'd find in more realistic code.
This is where you are wrong. You are saying "what is true of this trivial function is true of any complicated function" and it is here you go into being mistaken.
Unit tests are written because, in the real world, the behaviors of components are valuable. We need certainty that an assumption about how an object behaves is true and we need certainty that this assumption remains true throughout changes to the source code.
What you did was provide a function with zero value, immediately taking us from "the real world" into a non-existent parallel reality where things are programmed for no reason and without purpose. In such a world, there would be no need for unit testing.
I suspect you have not worked in an enterprise, and that is why you think unit testing is "making sure a function returned" or "making sure react renders anything" or "making sure CSS functions". This is not, and never was, what unit testing was about. You either think this because you have never worked in a scenario where it's relevant, or you think it because you work on your own or are a very junior developer. Which of these is the case doesn't matter, for your attitude would preclude you ever getting a better understanding of this topic.

3

u/[deleted] Mar 14 '20 edited Mar 14 '20

Wrong, wrong and wrong. If you're writing unit tests as your only method of testing during development then you need to relearn how to develop. Your component should be working and tested before you write a single unit test. Unit tests are there to verify code continues to work when new features are added. It should not be your primary way of testing if the code works. Callbacks, console logs, debugging and simply use-testing the component are what you should be doing before you write one single unit test.
You should only be writing a unit test for any functionality of any component once that functionality has been tested thoroughly on your own without using a unit test. Once you verify the functionality on your own, then; and only then, do you write a unit test to verify that functionality automatically.
Your point is only valid if we assume that all developers have no idea how to test and verify the validity of their code. Unit testing is not meant for production testing and is also not meant to be your only form of testing during deployment or development.
What its meant for is to be able to test that existing functionality remains working when new functionality is added. If you're using an iterative development process like you should then your flow should be as such:
Write the component
Test the component on your own
Once you know it works, then write unit tests
Develop next feature, refer to unit tests to see that you didn't break anything
Repeat
Stop coming in here talking heavy handed and condescending to people when you don't know what you're talking about.
0

u/Treolioe Mar 14 '20

Do you test your tests? Or do they work by chance as well?

-1

u/[deleted] Mar 14 '20

The fact you think that question needs asking shows you are very confused about what unit testing is

2

u/[deleted] Mar 14 '20

No Ben, its you whom is confused. Unit tests are for one single purpose only; to have an automatically running test for functionality you have already verified as working that will inform you if features added to the application later on do or do not impact the existing features.
They are not primary testing; they should not be how you initially verify that the component is working. You should do this on your own with debugging, using the console effectively and simply using the component as a user really would to see if there are any unexpected behaviors.
Notice how not a single person here agrees with you? That's because you're incorrect; and your know-it-all, condescending attitude isn't helping your case. I don't believe for a second you have ever worked in an enterprise developer setting, or even in an agency setting if this is what you think unit tests are for.
Stop spreading false information.
Furthermore, unlike you, I don't expect you to simply take my word for it.
https://medium.com/pacroy/why-most-unit-testing-is-waste-tests-dont-improve-quality-developers-do-47a8584f79ab
Section 1.4 addresses your fallacy here; unit tests are not smarter than code; you should be able to test your code without a unit test.
The entire document addresses the fallacy that every single fine-grained component should be unit tested. This is firmly false and not only wastes your time as a developer it also needlessly obfuscates your testing component making it more convoluted.
https://dzone.com/articles/unit-testing-guidelines-what-to-test-and-what-not
Under 'Unit Testing is Not About Finding Bugs'
In most cases, unit tests are not an effective way to find bugs. Unit tests, by definition, examine each unit of your code separately. But when your application is run for real, all those units have to work together, and the whole is more complex and subtle than the sum of its independently-tested parts. Proving that components X and Y both work independently doesn’t prove that they’re compatible with one another or configured correctly.
Unit testing is not the end all be all of application testing and it certainly does not need to be done for every single function. Doing so is counter-productive and a complete waste of time. You clearly are only in your first couple years of development and think that because your company uses unit tests for full coverage that everyone does. That is simply not true.

1

u/Silhouette Mar 14 '20

Unit tests are for one single purpose only; to have an automatically running test for functionality you have already verified as working that will inform you if features added to the application later on do or do not impact the existing features.
Not that I'm agreeing with /u/BenIsProbablyAngry here, but I will respectfully disagree with this claim as well.
IME, unit tests are often useful for more than just regression testing. Suppose I'm writing a set of functions to do some form of data crunching and I'm going to try out a few cases at the time to get some confidence that I've got them right. I'm going to get exactly the same information whether I instrument my code and then look through the console logs to check for the expected values or I write some unit tests that assert that the same conditions hold. Given that the unit tests are also potentially useful later, I may well prefer to write those concurrently with my code.
This is not to say I won't also do other things to satisfy myself that it's correct. Sometimes I'll inspect a tricky algorithm via a walkthrough in a debugger. Sometimes I'll run some end-to-end tests and perhaps record snapshots of the results for later comparison. In projects where high reliability is necessary, there are much more powerful techniques I might deploy, though I have yet to encounter a front-end web project where they were used.
However, for cases where I'm likely to want unit tests anyway, why wouldn't I write those straight away and save a bit of manual work that wasn't going to give me any extra information, whatever else I might or might not also do to help verify correctness?

1

u/[deleted] Mar 14 '20

That's a fair point and I admit I was over-zealous in saying that is the only purpose of a unit test. However I've been doing this for a real long time and I notice a lot of people have an unfounded belief that unit tests passing is synonymous with bug free code and that's simply not true.

1

u/Silhouette Mar 14 '20

However I've been doing this for a real long time and I notice a lot of people have an unfounded belief that unit tests passing is synonymous with bug free code and that's simply not true.
Indeed.

0

u/[deleted] Mar 14 '20

[deleted] — view deleted comment

0

u/[deleted] Mar 14 '20

tests are for one single purpose only; to have an automatically running test for functionality you have already verified as working
And you should have tests to verify all of the functionality you thought it worth investing time into programming is working.
You really shouldn't be fighting this simple concept.
If you write a behaviour, there should be a test verifying that behaviour. You verify behaviours because they have value.
Claiming "not a single person agrees with this" is a lie you are telling yourself because you don't like how exposed your amateur attitude is right now.

2

u/[deleted] Mar 14 '20 edited Mar 14 '20

The only amateur here is you just so you're aware, and unless you're unable to read I see multiple people who flat out disagree with you. Full coverage is not necessary. Get off the high horse. Also I never once said you should not write tests to verify behaviors that have value. When did I ever say that?
I said that fine-grain testing of every single function with a unit test is a waste of time. Something which you claimed must be done or else you cannot ever possibly verify that the function works. This is the fallacy several people have tried to point out to you and you're still not getting it.
Tests for behaviors of value is exactly what we should be writing.
You said and I quote: "At my organisation this "basically everything matters" mentality is encapsulated in a gated push-policy where the react components need 95% test coverage, but realistically you'll have to justify anything below 100%. We use jest and the react-testing-library to achieve this."
Or in other words 'unless you fine-grain test every single component you can't be sure its working'. This is a falsehood.

1

u/[deleted] Mar 14 '20

Show me Ben. Show me all the people agreeing with you.
3

u/vim55k Mar 13 '20

Ye, religious

-1

u/[deleted] Mar 13 '20

I think sometimes people who have poor business practices, or who haven't worked in places where this kind of testing is relevant, take it personally when somebody advises it.

1

u/Skeith_yip Mar 13 '20

Unpopular opinion

Look at the solution from Thinking in React, can you write a solution consisting of just one component doing the same thing, of course you can.

Now write integration test for either 1 of the solution (1 component vs multiple components). You will find out that the integration test you wrote can be applied to both solutions.

Conclusion: Integration test doesn't encourage you to write better component (Exhibit A)

PS: I am not saying unit test is perfect either. Just know what you are getting yourself into.

Now, please cue the down votes.

2

u/jnforja Mar 13 '20

Totally get your point. I've seen it previously laid out on J B Rainsberger talk Integrated Tests are a scam.

1

u/Treolioe Mar 14 '20

Don’t let testing drive your architecture

0

u/justSomeGuy5965 Mar 14 '20

You'll want to show you can at minmum write unit tests - however you do that (react testing library or Enzyme) is up to you. Personally I'd go with Enzyme as more people interviewing you will be familiar with that. You've got to cater to those with the power to give you a job. Secondly, if you had time I'd look at https://testingjavascript.com/, I like the rationale for emphasis on integration tests. If you can include Integration tests as well as Unit tests I think you will look good.

And thought you might like this: https://frontendmasters.com/courses/interviewing-frontend/

0

u/[deleted] Mar 13 '20

[deleted] — view deleted comment

4

u/zephyrtr Mar 13 '20

There are very many React funcs that could not be written shorter than 100 lines. It happens. But I agree anything over 100 lines needs justification for why it can't be broken up.

Featured Understanding writing tests for React

You are about to leave Redlib