smarter action shuffler#6
Conversation
069f414 to
a0db740
Compare
| import com.atlassian.performance.tools.jirasoftwareactions.api.actions.BrowseBoardsAction | ||
| import kotlin.reflect.KClass | ||
|
|
||
| class ActionShuffler { |
There was a problem hiding this comment.
It's not part of the API, so it could be internal, not to expose public non-API classes (it can be used by accident and expected to be compatible).
|
@pbruski Why do we need a smarter shuffler? What problem does it solve? AFAIK the current one will skip some actions at the beginning, but it shouldn't be a problem (skipping is cheap and fast). On the other hand, the smarter one does assumptions on the scenario and introduces extra complexity. Are there other advantages of the smarter shuffler, that would justify introduced complexity? |
| issueKeyMemoriser: Action): List<Action> { | ||
| //createIssue needs a project - browserProject goes first | ||
| //viewIssue needs to have issues - createIssues goes second | ||
| //viewBoards needs to know about boards |
There was a problem hiding this comment.
A unit test would be a better way to explain and protect such contracts.
BTW this function could be internal too.
| jqlMemory = jqlMemory, | ||
| issueKeyMemory = issueKeyMemory | ||
| ) | ||
| val findInitialIssues = ActionShuffler.findIssueKeysWithJql(jira, meter, issueKeyMemory) |
There was a problem hiding this comment.
IMO it violates SRP. It doesn't seem to be the responsibility of shuffler to findIssueKeysWithJql.
| import com.atlassian.performance.tools.jirasoftwareactions.api.actions.BrowseBoardsAction | ||
| import kotlin.reflect.KClass | ||
|
|
||
| class ActionShuffler { |
There was a problem hiding this comment.
The action is so tightly coupled with the scenario, that I would consider making it a private class. It doesn't feet to be reused even in the internal scope.
|
Related: atlassian/jira-actions#39 |
a0db740 to
af821af
Compare
No description provided.