Daniel Watford writes:
> We already have a +1 from James. Can I count on your vote, Mathieu? :)
You have a +0 on my side. As I already said I support the testing effort
because OFBiz need people caring about writing maintainable tests and I
found legitimate to introduce an extra mocking librar
Le 05/03/2020 à 14:18, Jacques Le Roux a écrit :
Le 05/03/2020 à 12:07, Daniel Watford a écrit :
In summary, I'm asking the community to accept introduction of a new
mocking library to support a longer term piece of refactoring work.
Committers! Bring me your +1 and lets get these PRs merged :)
Le 05/03/2020 à 12:07, Daniel Watford a écrit :
In summary, I'm asking the community to accept introduction of a new
mocking library to support a longer term piece of refactoring work.
Committers! Bring me your +1 and lets get these PRs merged :)
I'm actually focused on something else, but I i
Hi Mathieu,
Apologies if gmail mess up email quoting.
On Thu, 5 Mar 2020 at 10:33, Mathieu Lirzin
wrote:
>
> PS: Votes in regards code modification in a community with PMC members
> that basically disagree on everything else than “We are an awesome
> community” is not a solution to anything bec
Daniel Watford writes:
> Yes I agree that mocking of static methods is an indicator of refactoring
> needed.
>
> There are always exceptions to every rule, but in this case with
> MacroFormRenderer longer than
> 3000 lines in R18 and its role is to map from ModelFormField instances to
> string re
+1
On 2020/03/02 16:52:08 Daniel Watford wrote:
> Hi Mathieu,
>
> Yes I agree that mocking of static methods is an indicator of refactoring
> needed.
>
> There are always exceptions to every rule, but in this case with
> MacroFormRenderer longer than
> 3000 lines in R18 and its role is to map fr
Hi Mathieu,
Yes I agree that mocking of static methods is an indicator of refactoring
needed.
There are always exceptions to every rule, but in this case with
MacroFormRenderer longer than
3000 lines in R18 and its role is to map from ModelFormField instances to
string representation
of FTL macro
Hello Daniel,
Daniel Watford writes:
> I don't have a preference between the two mocking libraries, but creating
> unit tests for MacroFormRenderer necessitates mocking static methods.
> Mockito doesn't offer static method mocking, but JMockit does.
> [...]
> To provide unit tests for MacroFormR
Hi Michael,
I don't have a preference between the two mocking libraries, but creating
unit tests for MacroFormRenderer necessitates mocking static methods.
Mockito doesn't offer static method mocking, but JMockit does.
There are work arounds, but I think will be too cumbersome and brittle to
be e
Hi Dan,
why would you prefer JMockit over Mockito?
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 02.03.20 um 11:23 schrieb Daniel Watford:
Hello,
There are two outstanding PRs on OFBIZ-4035.
https://github.com/apache/ofbiz-framework/pull/26 should be considered low
risk as it com
Hello,
There are two outstanding PRs on OFBIZ-4035.
https://github.com/apache/ofbiz-framework/pull/26 should be considered low
risk as it completes a minor missing piece of functionality for generating
the DOM element id for container fields created in form widgets.
https://github.com/apache/ofb
Hello,
I've replaced the original PRs with a few more focused ones:
https://github.com/apache/ofbiz-framework/pull/24
https://github.com/apache/ofbiz-framework/pull/25
https://github.com/apache/ofbiz-framework/pull/26
Hopefully the above are considered low risk and/or minor improvements and
can
Hello,
Two PRs have been created to address this ticket - please see comments in
jira.
The first PR is mostly a documentation change as it turned out the required
functionality already existed.
The second PR introduces some unit testing, but to be able to test
MacroFormRenderer without an explos
13 matches
Mail list logo
