[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epp-dev] Package maintainers are you testing your packages?
|
Thank you for your insights. Probably the time consuming part for us is that we have our automatic tests geared to Scout internals and the manual testing is more in the way others would use our build, e.g. via Oomph and m2e, and additionally
on platforms we don’t use ourselves regularly (Mac comes to my mind). If something goes wrong it might not be immediately clear whether it is a problem of our own making or an upstream issue. I have to think of some kind of automatic integration tests which
cover our use cases.
On another note I am always surprised by how fast some projects have their +1s ready. How do you do that? Our builds go through automatic testing which is (relatively) fast. But
the manual testing of EPP builds takes us quite some time and sometimes it’s not immediately clear if an issue found has anything to do with the build or is just some local problem of the tester. Any secret sauce you are using from which we might profit too?
FWIW, for Rust and _javascript_, as the components have good test coverage on their end and are usually already released before joining EPP, I simply run a few very small scenarios and simple which cover about everything, basically:
1. Create/import a project with dedicated wizard
2. edit some files to see validation, completion, hover, outline working (I trust the rest is tested by each brick)
3. Try the Run As/Debug As and ensure those work
Unless I'm stuck in any of those tasks, I vote +1 (even if there is a known bug, as long as it's non-blocking and reported).
That allows to spend less time on specific EPP testing, and my experience is that in order to avoid bugs downstream (in EPP or other) then keeping focus on quality in the actual upstream components (Corrosion, Wild Web Developer) with regular
builds, good test suites, managing dependency range at best... makes that a simple 5/10 minutes test for EPP seems enough to me.
ie the more trust you build on the component itself, the less downstream consumers like EPP are likely to require QA.
This is the process I have inherited for CPP too. With EPP I am focused on the integration being in a working state and letting individual projects ensure their contributions to SimRel are good enough. I think the biggest hole in testing
is the cross platform testing. Most packages (AFAIK) are only tested on a single platform, but every platform seems to be tested by at least one package tester.
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
