On Wed, May 11, 2022 at 7:32 AM Tim Jacomb wrote:
> Recently both Jan and myself have hit a number of issues with HtmlUnit not
> supporting modern JavaScript. (You implement it and it works fine in the
> browser but then the PR test builder blows up and you need to re-implement
> it)
I'm in favour of this although I can't dedicate time to it currently.
> Whatever we have, if we end up having ATHs on core PRs to detect
regressions early then we need to be prepared to maintain the ATH
tests/framework or to not accept the changes.
If PRs break the ATH and they are in the same
Going back to the earlier premise
> It seems to me that a number of problems are caused by ATH tests being
in a separate repository from the code under test
I would say the biggest problem is not so much that - rather that we do not
run enough of these tests for the code that is affected, early
> Am 26.04.2022 um 18:28 schrieb Basil Crow :
>
> On Tue, Apr 26, 2022 at 7:45 AM Ullrich Hafner
> wrote:
>
>> Those tests will run in a special docker container with a headless browser
>> (chrome or firefox).
>
> Ideally, I think we would want to support both Dockerized and
>
On Wed, Apr 27, 2022 at 9:06 AM Ullrich Hafner wrote:
>
> This will depend on the type of the plugins. In my analysis plugins my tests
> start by creating a freestyle job or pipeline. There is no previous setup
> required. I don't think that this can be speed up with job-dsl or something
>
> Am 27.04.2022 um 12:37 schrieb 'Antonio Muñiz' via Jenkins Developers
> :
>
> I was working/planning with Oliver for some time on this. One of the
> identified downsides of this approach is that the Jenkins UI does often
> evolve in a backward incompatible way (ie. table to divs change,
>> Although ATH uses RESTish endpoints for a few purposes, for the most part
>> the test setup (not just the actual assertions) uses the browser. In all
>> cases the whole test run is “black-box”. This has its appeal (stronger
>> coverage) but GUI setup makes tests much slower and either REST
On Wed, Apr 27, 2022 at 3:37 AM 'Antonio Muñiz' via Jenkins Developers
wrote:
> unless some complicated pipeline is put in place to run ATHs from some key
> plugins as part of the Jenkins core build
Yes, implied in this proposal was running the plugin BOM/PCT tests
(which, as of this proposal,
I was working/planning with Oliver for some time on this. One of the
identified downsides of this approach is that the Jenkins UI does often
evolve in a backward incompatible way (ie. table to divs change, plugin
manager recent changes, etc), all those potential breaking changes would
not be
On Tue, Apr 26, 2022 at 11:12 AM 'Jesse Glick' via Jenkins Developers
wrote:
> `acceptance-test-harness` has a bunch of dependencies some of which clash
> with those in Jenkins core or some plugins, so you would need to either shade
> them all, or otherwise somehow ensure the ATH dependency
On Tue, Apr 26, 2022 at 12:28 PM Basil Crow wrote:
> I wonder if we could design a system such that for the common case only a
> single Maven project is needed
Sounds tricky. `acceptance-test-harness` has a bunch of dependencies some
of which clash with those in Jenkins core or some plugins,
On Tue, Apr 26, 2022 at 7:45 AM Ullrich Hafner wrote:
> Thanks Basil for bringing this topic to attention!
You are welcome!
> […] I already converted several plugins in the way you are suggesting […]
I am pleased that this approach has been working well in your plugins.
Assuming that the idea
Thanks Basil for bringing this topic to attention!
I am all in for this new approach! I think when we spend time to write UI tests
(which are expensive to write and maintain, and slow to run, see test pyramid
of Mike Cohen) then we should consider to run them as real system tests using a
real
Hi all,
It seems to me that a number of problems are caused by ATH tests being
in a separate repository from the code under test. When regressions
occur, they are not discovered until much later. This causes pain for
those who investigate ATH test failures. If the ATH tests were moved
to the same
14 matches
Mail list logo
