[TYPO3-mvc] [RFC] Keeping FLOW3 Compatibility

[Sebastian Kurfürst]

Hey,

> I hope nobody takes a down-vote personally (you really shouldn't). Here though, you touch on something that I think we could streamline a lot by having a QA person in Extbase. Effectively somebody responsible for the current state of the git master and code coverage of the unit tests. A lead dev if you will.
unfortunately, I think that just doesn't work, as we and other teams
have tried that often. You cannot delegate the testing-responsibility to
one person and let all the others do the "cool programming" ;)

In fact, unit testing mostly only works if implemented right alongside a
feature...

> Just as an example, I truly and sincerely suck at writing unit tests but I like to think that I don't suck nearly as much at writing effective code. So while I learn this unit testing heebajeebee my unit tests are bound to be basic - and I would hate to see this become a blocker.
That's not a problem IMHO, as we can give feedback or provide followup
patches with better unit tests. However, this should happen in *gerrit*
and not in the git master. Once something landed in master, people tend
to forget about the open issues ;) (myself included... ehrm)


> But such a requirement does make Extbase development a lot less flexible and to me, this should be a big concern of ours.
IMHO we have areas with quite good code coverage, and others with
not-so-good one... My main point is that we should make sure that the
areas which are covered by unit tests will not degrade; i.e. we should
also add unit tests when we add features to them.

>> Another example for such a feature relevant to FLOW3 would be:
>> https://review.typo3.org/#change,4440
> You definitely know better than me what works for FLOW3 but the main reason for doing the change above was that we don't have namespaces in Extbase and needed a more FLOW3-shorthand-like way of using custom validators. Would it not almost take more to do the same if you use fx Vendor\Package\ValidatorName instead of Namespace\ValidatorName?
IMHO the FLOW3 equivalent would be:

Vendor.Package:ValidatorName

> Excellent point! This could be the practical solution to a back-communication problem. As long as this does not become a reason for FLOW3 gurus like yourself to no longer stay interested and active in Extbase ;) v4 still has a lot of good years to come.

>> Furthermore, we should ensure that changes in these areas are covered
>> with unit / functional tests, as we have quite some in this area
>> already, and we should make sure that the test coverage doesn't shrink
>> because of "so many features so little time"...
> I would love this - but don't you think it makes sense to have a person dedicated to QA in order to keep things flowing and loosen up commit restrictions a little?
as explained above, we tried to loosen up commit restrictions a couple
of times in FLOW3, and always this has lead to worse quality... So IMHO
we *need* to stick to our review work we do in gerrit.

If bigger features should be developed collaboratively, I'd suggest to
use GitHub or personal sandbox branches for that. But then, the feature
gets merged *as one step*.

> Yes to the double issues, absolutely! This could also let us track if some behavior in FLOW3 changes. A point though - shouldn't the opposite also be done if for example there is a bug detected in FLOW3's error handling - Extbase would need a forge issue as well?
Certainly true and that's something we definitely need to improve.

> Perhaps we could find a way to make it very clear exactly when such a double issue is required so there is no room for error? Can redmine for example do something based on an issue's category...?
We should try to come up with some guidelines on a wiki page, but aside
to that I guess that's a manual process.

> And to avoid slowing down development I propose either having a dedicated QA person or allowing unit tests to be improved in, just as an example, sprints. I think this could keep the momentum up without disconnecting code and quality. All we would really need is a way to coordinate when/where unit tests need improvement.
Unit tests always need improvement ;) I just think it doesn't work that
way... You either create unit tests alongside your code, or you never do it.

Who in the audience has written unit tests for code which already
worked? I, for one, didn't...

> Can Fuzzing perhaps do something for us Extbase folks in that regard? ;)
No, that only gives hints about how good your code coverage metrics are,
nothing more nothing less.


Thanks again for this prodcutive discussion,
Sebastian