Re: Porting tests to plone.app.testing and removal of legacy packages

"Jens W. Klein" <jens-/[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Organization Klein & Partner KG
Message-ID <[email protected]>
The problem is plone.app.testing.bbb load ATCT profile in setUp

	testing.applyProfile(portal, 'Products.ATContentTypes:content')

https://github.com/plone/plone.app.testing/blob/master/plone/app/testing/bbb.py#L42

i suppose it silently ignoed if ATCT is not there, but thats not the 
case in the Archetypes test case.

When running

	./bin/alltests-at --group=CMFEditions

This results in a
	
	ValueError: undefined property 'content_meta_type'

Because for some reson priot to the ATCT profile the pa.ct. profile was 
loaded and so a AT/old school FTI defintion want to be loaded on an 
existing DexterityFTI. Which as it seems does not have such a property 
any more.

I think here we have two problems. One is the dup loading of the FTIs. 
Second is the very bad error messages and checks inside GenericSetup 
which makes it horrible difficult to debug what happens here.

Any ideas how to fix this?

I fear there are other problems left anyway.

Jens

On 2015-01-28 16:53, Gil Forcada Codinachs wrote:
> There is a failing test still, but somehow jenkins fails to report that one.
>
> As jensens said is on p.a.testing.bbb ....
>
> 2015-01-28 16:40 GMT+01:00 Gil Forcada Codinachs
> <[email protected]
> <mailto:[email protected]>>:
>
>     I did the last reverts (one at a time again and created new PR for
>     them[1]).
>
>     P.CMFDynamiViewFTI was reverted but still has two failing tests(?!)
>     P.PloneLanguageTool was manually reverted[1] and is running now on
>     Jenkins:
>     http://jenkins.plone.org/job/plone-5.0-python-2.7-at/3597/
>
>     If the above job does not end up in a green build, we will start to
>     have to look somewhere else...
>
>     Cheers,
>     Gil
>
>     [1] there were two more commits after the p.a.testing merge
>
>
>     2015-01-28 16:07 GMT+01:00 Timo Stollenwerk
>     <tisto-z4DKO/[email protected]
>     <mailto:tisto-z4DKO/[email protected]>>:
>
>         Am 28.01.2015 um 14:30 schrieb Johannes Raggam:
>         > Please track these reverted packages. The pull request on that packages
>         > is closed and if we forget to revert the revert, the changes are lost in
>         > history.
>         >
>         > I'd rather give people a bit more time, say 48hrs or try to fix the
>         > breaking tests myself. Everyone should feel responsible to fix a failing
>         > test.
>
>         I strongly disagree. If we have the build broken for a longer
>         period of
>         time we basically have two options:
>
>         1) People stick with the CI rules and do not work on Plone at
>         all if the
>         build is broken. Do we really want one person to be able to
>         block every
>         other Plone dev for 48 hours? Who is going to check that? Who is
>         going
>         to act after those 48 hours? Do you want to do this manually?
>
>         2) People ignore the CI rules and commit on a broken build. This
>         leads
>         to a situation where it is impossible to figure out who broke what.
>         Nobody feels responsible and we have a red build forever (e.g.
>         the old
>         way of doing things).
>
>         "Everyone should feel responsible to fix a failing test." equals
>         "nobody
>         really IS responsible".
>
>         I would consider our CI to be completely broken in both scenarios.
>
>         > Especially because on the Plone 5 AT job it's IMO not that urgent to
>         > have a green build within a few hours.
>
>         My experience with CI systems is that saying "it is not that
>         important"
>         is the worst thing you could do. If we start saying that things
>         aren't
>         important and that we can fix it later, it will be broken
>         forever and
>         nobody feels responsible.
>
>         The beauty of a well tuned CI system is that it gives developers
>         feedback immediately if they break things, so they can fix it
>         immediately and with not too much effort. If another person has
>         to fix
>         this later it cost way more effort (and is also a bit unfair in my
>         opinion). If we let that core principle of CI go, we loose most
>         of the
>         advantages.
>
>         Timo
>
>         ------------------------------------------------------------------------------
>         Dive into the World of Parallel Programming. The Go Parallel
>         Website,
>         sponsored by Intel and developed in partnership with Slashdot
>         Media, is your
>         hub for all things parallel software development, from weekly
>         thought
>         leadership blogs to news, videos, case studies, tutorials and
>         more. Take a
>         look and join the conversation now.
>         http://goparallel.sourceforge.net/
>         _______________________________________________
>         Plone-developers mailing list
>         Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>


-- 
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.