You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we only track the factory name/id when collecting information about factories usage. However, for refactoring and context extraction purposes it would be useful to also see common variations (traits and attribute overrides).
TODO
Add variations information to the FactorProf data and print it in the FPROF=1 report. Example format:
[TEST PROF INFO] Factories usage
Total: 15285
...
name total top-level total timetime per call top-level time
user 6091 2715 115.7671s 0.0426s 50.2517s
.admin 123 715 15.7671s 0.0466s 5.2517s
[name,role] 25 11 7.671s 0.0666s 1.2517s
post 2142 2098 93.3152s 0.0444s 92.1915s
.draft[tags] 12 12 9.3152s 0.164s 42.1915s
...
In the example above, .xxx indicates a trait and [a,b] indicates the overrides keys, e.g., create(:user, :admin) is an .admin variation, while create(:post, :draft, tags: ["a"])—.draft[tags]. We do not distinguish values, only schemas.
Implementation notes
FactoryProf collector should receive the variation name from the outside and should not deal with traits, overrides, etc. Thus, we need to extends the #track methods with the variation: keyword argument
Overrides keys and traits must be sorted (since the order doesn't matter)
It makes sense to add a specific variation id for variations with too many traits or overrides ("too many" must be configurable); e.g., create(:post, title: "RailsConf", publish_at: 2.days.since, tags: ["a", "b"], author: user) would be marked as [...].
The text was updated successfully, but these errors were encountered:
Context
Currently, we only track the factory name/id when collecting information about factories usage. However, for refactoring and context extraction purposes it would be useful to also see common variations (traits and attribute overrides).
TODO
Add variations information to the FactorProf data and print it in the
FPROF=1
report. Example format:In the example above,
.xxx
indicates a trait and[a,b]
indicates the overrides keys, e.g.,create(:user, :admin)
is an.admin
variation, whilecreate(:post, :draft, tags: ["a"])
—.draft[tags]
. We do not distinguish values, only schemas.Implementation notes
FactoryProf collector should receive the variation name from the outside and should not deal with traits, overrides, etc. Thus, we need to extends the
#track
methods with thevariation:
keyword argumentOverrides keys and traits must be sorted (since the order doesn't matter)
It makes sense to add a specific variation id for variations with too many traits or overrides ("too many" must be configurable); e.g.,
create(:post, title: "RailsConf", publish_at: 2.days.since, tags: ["a", "b"], author: user)
would be marked as[...]
.The text was updated successfully, but these errors were encountered: