-
Notifications
You must be signed in to change notification settings - Fork 281
Ability to specify order of the transactions #456
Comments
@tu1ly Cool idea :) Did this cause an issue for you? Would it be difficult to keep track of two lists of transactions—one in the blueprint and one in your Dredd hooks/configuration? Would the ability to randomize the tests be a solution here? |
Maybe the "only" option's array order could be used as first implementation? |
I ran into the same issue today, I ended up using the var order = [
// Your API names in the wanted order of execution
]
hooks.beforeAll(function(transactions, done) {
transactions.sort(function(a, b) {
var aIdx = order.indexOf(a.name)
var bIdx = order.indexOf(b.name)
return aIdx - bIdx
})
done()
}) |
@Souler This is an interesting solution! Just to add to the discussion, Dredd is primarily a tool designed to perform isolated tests and hooks are here to help you to isolate each test. See docs on this. If you need to order your transactions, it's a sign you're not creating isolated tests. YMMV if that's good or bad. |
@Souler Thank you very much! You saved my day! |
Closing in favor of #995 |
Not working for me @DrEdd v12.0.7 |
@shivshankar3578 Could you share more in a separate issue with a full bug report? This should work. |
And in
I'm not getting GET /services/ug/{id} First |
What does |
No, it doesn't and I'm reassigning transactions again after modification. It's not immutable also.The Array functions (filter, sort or map) return a new modified array so I need to reassigning it again. |
It cannot be reassigned. This is a hack which counts with the fact that you modify the original array, the one |
Got it, but it's a bit confusing, Either you should freeze the array or impl. it using immutable way |
It is confusing, it is a kind of a hack. As you say, ideally there would be a nice immutable interface to achieve this. We're working on decoupling things in Dredd internally which would allow that in the long run. |
current:
Dredd runs the transactions as they’re specified in blueprint.
expected:
ability to define transactions order. Othervise 2 blueprints which are sematicaly the same could behave differently when sharing data across the transactions
The text was updated successfully, but these errors were encountered: