Post

No and usually yes

kentcdodds.com/blog/the-tes...

But please note that the testing level separation is not something you should dwell upon. In a sense that I don't care if it's technically a unit test or a functional test or an integration test. What I care is the boundaries of my test and a working product. Test bits, then test synergies.

Hm. I think drawing a line at your app's logic helps. Typing into an input may involve a bunch of behaviors on your UI framework's side, but those aren't your concern. Putting yourself in your user's shoes also help (does my user know about this? no, then it's not my concern either).

This framework of thinking helps me make sense of the testing levels. Whereas basing them on logic was always confusing to me, and it inevitably leads to spending time in discussion instead of spending that time on testing.

Still learning the ropes! Thanks.

For an open source library, for example, e2e implies packing and installing your package in a test project, then interfacing with it akin to the package's consumer. Similar intent, different specifics inherent to the kind of software.

There could be a UI integration test, but there could be a backend integration test also (e.g. server side controller communicating with a real socket via HTTP but nothing more than the connection itself, e.g. no DB queries). All in all both E2E and integration could test entire user flows.

Very, very close to how I think of integration tests 👍

Having a common definition helps for teaching. So clarifying the def you use is helpful. But the different shapes of testing strategies are mostly marketing. Testing pyramid, trophy, crab, honeycomb... Under the hood it's the same advice with different definitions of where you draw the line

I draw that line in that submitting a form likely involves multiple things in my app: input state handling, validation, triggering the actual submit. It's a compound behavior, whereas a function call is a simple behavior if we draw the line at function's I/O.

I think of it this way: - Unit tests are for spec definition - Integration tests are for quality assurance - E2E are for system integrity

test across boundaries no probably not

I'll throw my view into here: - An integration test (as opposed to a unit test) involves something that is not defined in the codebase under test. 3rd party API, DB, etc. - E2E tests the full stack, often including several integrations. - Typically yes, but calling it a component test is easier.

I’m struggling to find the source, but I go by these rules. Integration tests do at least one of: use the network use a database use i/o cannot run in parallel

Integration tests are a subset of end to end tests and test an integration of layers in your application. For example your back end API with your dB. End to end tests all the integrations. As for RC, it could be either unit or integration depending on scope of what is actually being tested.

i personally use integration and end-to-end interchangeably in the context of frontend code. testing a react component is a unit test for a UI render function my spicy answer for the second question is that testing a React component is a “waste of time” in my experience

Testing a react component can be many types of test. If the paradigm of the application is a thick client. Then the component can have a lot of responsibility. I would argue that testing a react component can vary from e2e to unit test dependent on the scope the component is responsible for.

Integrations tests are different from e2e as they typically mock services and they test apis. Also they can be done solely on backend services or solely on some FE components E2E usually are requirement / user story focused. E2E both assert front- and backend.

can't answer the 2nd question, but we consider integration test when we cross platform software testing and end-to-end is more a network consideration of the same cross platform software testing.

Hm I'd say no and sometimes. You could also have a react component test that is a large component and tests the interactions between other components and services. I guess a type of integration component test 🤷‍♀️

An e2e test goes from user input/interaction to final output. All the “real” services etc. are used without mocking. Typically this is done using a test deployment.

I like that

The way I think of it is: "end to end" is if you test how the end user would experience it (so an actual browser / device all the way down). A "unit" test is testing a single function (so a React component is indeed a unit test). And an "integration" test is anything in between.

Try it! Most of the time we agree but get hung up on pedantic terminology.

Maybe tweak that - choose labels based on the distinctions you need to make - eg if you have some expensive tests that only run nightly, label them accordingly. If you don’t need to distinguish, just call them all “tests”.

and yeah i think I would consider testing a react component a unit test

and yeah i think one could refer to e2e as an integration test its just that e2e makes it more clear that there aren't any mocks or boundaries applied.

The best time to do stress test is after successful e2e test. Up the volume and see what breaks...

But mostly I think the only thing that matters is having consistent nomenclature within a project or team, less about all software everywhere.

Well put.

To me any test that requires dependency injection or mocking internal dependencies is very hard to consider a unit test, no matter how small it is. So to me most tests fall in the integration category, including most React components. An e2e test is the ultimate integration test.

React sucks at unit/integration testing b/c React itself is a 'God Object' anti-pattern. Ie. you can't test any of its parts individually without bringing in the whole framework. In React only E2E testing is feasibly worth the effort.

Shortly, "is testing a React component a unit test?" is in itself not a valid question. A React component test can be a unit test. It can also be an integration test. The testing level changes based on the behavior you want to test. Single behavior = unit test. Multiple behaviors = integration.

I think we should stop using those words. instead have a look at this: www.awwsmm.com/blog/there-i...

👀

End to end tests should test business process from end to end. Integration tests simply test interactions between different parts and are usually smaller in scope then end to end. Unit tests test a single class or component in isolation.

It’s all perspective. One units test is another’s integration

martinfowler.com/bliki/UnitTe...

Yeah, I'm also team "it doesn't matter" and "I don't care." Is the test providing value? Is it fragile? Does it break when you make a normal change? I think the testing pyramid is an outdated idea. When it's up to me, I test using whatever the thing's API is and nothing else.

Yes absolutely agree

To expand on this and where I got it from, it’s how Google does it, with an explanation as to why here: testing.googleblog.com/2010/12/test... Basically avoids the “oh **that** kind of integration test” confusion.

For me, unit tests are the ones best written as you specify the component in question and you have it from the get-go, they are tightly bound to their components. Some testing protocols for a whole product or set of components can be written early, but they aren't so tightly bound.

The distinctions can be meaningful - for example any change that breaks an e2e test is by definition semver major.

For me: Unit test -> test a part of an app that doesn't rely on external services Integration -> test a part of an app that relies on external services that are mocked End to end -> test a part of an app that relies on external services that are not mocked

free yourself from thinking about what a unit test is or not, and focus on if the test is useful or not

To me a unit is just testing a building block, often in isolation w/ a vague “does this generally work”. Integration & e2e tests aren’t super clear to me beyond the size of their coverage in terms of application code and/or feature function.