Timeline for Extracting pattern and simplifying testing
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 28, 2013 at 11:24 | comment | added | svick | @abatishchev I was trying to make the usage syntax as simple as possible. I think that a more complicated syntax (like the one suggested by Dan) wouldn't actually improve the code. | |
| Dec 28, 2013 at 7:30 | comment | added | abatishchev | Your solution is really answers my question! But more in "how to refactor" and less in "how I'd like to see it be refactored" or "how it should be refactored" :) | |
| Dec 28, 2013 at 7:27 | comment | added | abatishchev | The main drawback of your solution for me is that the number of "steps" is not dynamic but mandatory and hard-coded. So I need to have separate Chain() for a case of 2,3,4,etc. Also having T1,T2,T3,etc. degrades readability significantly :( | |
| Dec 28, 2013 at 7:22 | comment | added | abatishchev | No, that's current test name. I have such test for each member/dependency in the underlying flow. Everything is mocked up but still too messy. | |
| Dec 27, 2013 at 23:01 | comment | added | radarbob | Confusion. This code sample could/should be what the TEST method signature might be, yes? | |
| Dec 27, 2013 at 20:00 | comment | added | abatishchev | Thanks for your answer! I agree that the code is straightforward but its testing is unfortunately not, it's messy. I need to mock all dependencies turn by turn and make sure that the flow takes place (passing result from one to another). I feel like I'm testing a wrong thing. I'd like to have a set of strongly-typed flow steps and just make sure that SUT uses the flow manager. | |
| Dec 27, 2013 at 17:35 | comment | added | ChrisWue |
Maybe if you call it Chain it becomes clearer?
|
|
| Dec 27, 2013 at 11:20 | history | answered | svick | CC BY-SA 3.0 |