Add more testing: gRPC call failures

[eguzki]

* moved e2e to examples

• added failures integration tests removing tests on examples

[eguzki]

Clippy complain fixed in #154

[alexsnaps]

I'd drop b805299, examples/ has some semantics in a Cargo project

[alexsnaps]

Job done, so let's not throw this away, but I really think this kind of behavior should be tested for in unit tests, not solely in integration tests, these are (currently still) brittle and certainly slow given all the lifting that has to happen.

So let's work on this refactoring while we can and get the proper testing in place 🙏

[eguzki]

Dropped b805299

Job done, so let's not throw this away, but I really think this kind of behavior should be tested for in unit tests, not solely in integration tests, these are (currently still) brittle and certainly slow given all the lifting that has to happen.

Agree. But working on unittests would be a waste of time right now, with a huge refactor coming ahead of us. Anyway, I thought it would be a good progress to work on moving "example" tests to proper integration tests. Specially for one good reason IMO: The integration tests must pass as they are after the refactor. So we have good better test harness than now to support the refactor.

[didierofrivia]

so we are removing the integration e2e tests?

[alexsnaps]

so we are removing the integration e2e tests?

That wasn't my ask and I don't think we should... but I get really confused about what we are all trying to achieve with this code base at this stage...

I'd drop b805299, examples/ has some semantics in a Cargo project

Was about that commit... i.e. do not rename it to examples as it has some specific semantic attached to it within a cargo project...

[eguzki]

so we are removing the integration e2e tests?

I would not. But the desired behavior should be tested in unittests and integration tests as it fits (unittests and integration tests have different scope). However, having some "smoke" tests in e2e directory is also desirable IMO. Right now, there is one "basic" and one "remote address" e2e test. I would remove the "remote address" from that directory and move it to unittests and integration tests in following up PR's.

[eguzki]

I get really confused about what we are all trying to achieve with this code base at this stage...

If you are referring to code in e2e folder, my answer would be "smoke" tests... or call it sanity tests.. Something that exercises the module running it loaded in a real gateway.

[alexsnaps]

If you are referring to code in e2e folder

No, I was referring where you are all putting your efforts in. Based on my understanding of where things are and where we want to get them, there is work appearing that not only does not fit my understanding, but seem to only create more work for later to redo/refactor/move/... But the good news is I don't need to understand :)

So, again... all I was trying to convey is that Cargo considers ./examples/ in a special way... so don't use that name for a directory within a Cargo project other than for its intended use.

I guess @didierofrivia 's question was with regards to the stuff being deleted from e2e and "only" leaving:

./e2e
├── basic
│   ├── docker-compose.yaml
│   ├── envoy.yaml
│   ├── limits.yaml
│   ├── Makefile
│   └── README.md
├── remote-address
│   ├── docker-compose.yaml
│   ├── envoy.yaml
│   ├── limits.yaml
│   ├── Makefile
│   └── README.md
└── unreachable-service
    └── docker-compose.yaml

[eguzki]

I guess @didierofrivia 's question was with regards to the stuff being deleted from e2e and "only" leaving:

The stuff being deleted from e2e has been added to integration tests in tests/failures.rs.

[eguzki]

Based on my understanding of where things are and where we want to get them, there is work appearing that not only does not fit my understanding, but seem to only create more work for later to redo/refactor/move/...

That's sad. I really believed this work was in the right direction of having features tested in rust instead of heavy and slow environments as agreed. Not only valid for today, but also for later and does not create more work for later to redo/refactor/move ... 🤷