Yes, it makes sense to start supporting Junit 5 for new tests. This is the
reason why we should be moving the infrastructure out of base classes so that
the same test infrastructure could be used in TestNG and Junit 5 tests. One
example is the PulsarTestContext class which can be used in both ca
> The benefit of moving towards PulsarTestContext as the way to wire up things
> is that PulsarTestContext could also be used in Junit 5 when we start
> migrating away from TestNG.
> Perhaps we could enable Junit 5 for new tests and start moving to this
> direction? In BookKeeper, Junit 5 is ena
Hi all,
I raised a PIP PR here.
https://github.com/apache/pulsar/pull/23565
Thanks,
Heesung
On Sat, Nov 2, 2024 at 6:31 PM Heesung Sohn wrote:
>
> Hi,
>
> Sure. Let me open a PIP for Pulsar Test Improvement.
>
> I think I can summarize this discussion and document it as a PIP for
> future refe
Hi,
Sure. Let me open a PIP for Pulsar Test Improvement.
I think I can summarize this discussion and document it as a PIP for
future reference and as the agreed direction.
Thanks,
Heesung
On Sat, Nov 2, 2024 at 2:13 AM Lari Hotari wrote:
>
> On Sat, 2 Nov 2024 at 02:32, Heesung Sohn wrote:
>
On Sat, 2 Nov 2024 at 02:32, Heesung Sohn wrote:
>
> Hi,
>
> I agree with your points that there are tradeoffs between in-memory vs
> container test clusters,
> and that we should add more "unit" tests to cover behavior and avoid
> deep state checks.
> We should smartly move/add integ tests in in-
Hi,
I agree with your points that there are tradeoffs between in-memory vs
container test clusters,
and that we should add more "unit" tests to cover behavior and avoid
deep state checks.
We should smartly move/add integ tests in in-memory or container test
clusters, without increasing the test ex
I guess the problem is that most Pulsar tests are integration tests and there
aren't many actual unit tests for the most important parts of the Pulsar code
base.
There's also a lot of tests which test the implementation and not publicly
observable behaviors that is typically a recommendation. F
I agree, it's not optimal. In Pulsar, most tests that we call "unit tests" are
actually integration tests. Since there a lot of such tests which rely on
clean state (state cleared after every method), switching to some other
solution for these tests could potentially increase test times.
That's
Sounds good. Looking forward to it!
btw. We currently have 2 modules that are test libraries: "testmocks" and
"pulsar-testclient". The pom.xmls of those projects could be useful when
splitting out the test libraries.
-Lari
On 2024/10/31 22:15:03 Heesung Sohn wrote:
> Hi all,
>
> I think we can
Hi,
> if we're not going to mock some behaviors of ZK or BK, it might not be good.
I agree. I think we can put/move more tests in the integration tests,
especially for those tests that are based on client and admin calls
only.
Also, we need to think about how to optimize the integration test runs
This is a good start to. I have another suggestion. Currently we
relied heavily on mock ZK and BK services. However, if we're not going
to mock some behaviors of ZK or BK, it might not be good. I have
encountered the following error logs in the downstream application:
```
12:28:36.903 [ZKMetadata
LGTM, the current test code is relatively confusing, and this proposal can
improve this situation.
--
Best Regards！
crossoverJie
Heesung Sohn 于2024年11月1日周五 06:16写道：
> Hi all,
>
> I think we can refactor/split the `tests` module(the integration test
> module) to reuse the integration test code
Hi all,
I think we can refactor/split the `tests` module(the integration test
module) to reuse the integration test code better.
Currently, there are good test classes to reuse(such as topic message
test cases, container setup, and other test util funcs), but this
module is built under "test" sco
13 matches
Mail list logo
