Re: Event Modeling and TDD... somewhat
I think event modeling is poorly named. Yes these are the main events of the system, but no these won't be the only events. Some events will exist just for the systems sake.? It also doesn't capture state.
However, I find it a very useful tool, and works with TDD well.? Capturing and discussing the main events that the system must have, and their relationship from a business perspective, is useful in deciding where to start doing TDD. It also aligns business with developers and enhances the ability to do DDD.
The trick is to realize that event mapping mainly gives you a high level architecture with the critical paths that need to be covered to produce real business value. Its not intended to cover everything, but it is better than talking about vague goals of the system.?
I.e. we want a room added event, not just "make reservations". It helps you think about what you want to do with the reservation in the fist place. (The room added event can be sent to housekeeping and added to a reservation, and also sent to maintenance to check the lights are working, without compromising privacy)
On Fri, May 22, 2020, 04:20 Jeff Langr < jeff@...> wrote:
Hi JB,
It sounds like the New Message I heard c.2013 when Fred George said
"microservices are so small you don't need to write tests for them." I
asked Fred what he thought was small; "oh, maybe 100 lines of code." I
later read a book about the tao
of them that echoed this sentiment with numerous, similar putdowns
throughout.
Those with their fingers in typical codebases know full well the
impenetrable & defective mess that one can make in just 3-5 lines of
code, and the non-obvious nuanced behaviors it's possible to build into
not much larger bits of code.
I know many of us have been developing for some time. You reminded me
years ago that, as we move toward mastery, we think our ability to
discard "forms" (stand-ups, test-everything, etc.) means that everyone
should feel comfortable with doing so. We do need "beginner's
guidelines." And I still need TDD most of the time to continue going
fast enough.
I chalk this new New Message up to perhaps the same lofty levels of
experience that Mr Dymitruk may well have.
Then again, it's hard to get past messages like " TDD
offers little if you have your design in front of you" and feel gracious
at all.
Regards,
Jeff
|
| Jeff Langr / Langr Software
Solutions, Inc.?????
|
| ?+1-719-287-4335
|
|
|
|
J. B. Rainsberger wrote on 5/21/20 5:57 PM:
Hi, folks.
Adam Dymitruk
wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events,
instead", but I otherwise trust him, so I'd like to know whether you
folks have any experience mixing event modeling with TDD.
I
don't, but I can see how I'd do it, and I imagine people who practise
TDD will eventually (eventually!) see the benefits of event modeling as a
shortcut. Adam and I have made vague plans to discuss this in some
detail, but if you folks have anything to say on the topic, I'd enjoy
reading it. -- J. B. (Joe)
Rainsberger :: ::
::
|
Re: Event Modeling and TDD... somewhat
Hi JB,
It sounds like the New Message I heard c.2013 when Fred George said
"microservices are so small you don't need to write tests for them." I
asked Fred what he thought was small; "oh, maybe 100 lines of code." I
later read a book about the tao
of them that echoed this sentiment with numerous, similar putdowns
throughout.
Those with their fingers in typical codebases know full well the
impenetrable & defective mess that one can make in just 3-5 lines of
code, and the non-obvious nuanced behaviors it's possible to build into
not much larger bits of code.
I know many of us have been developing for some time. You reminded me
years ago that, as we move toward mastery, we think our ability to
discard "forms" (stand-ups, test-everything, etc.) means that everyone
should feel comfortable with doing so. We do need "beginner's
guidelines." And I still need TDD most of the time to continue going
fast enough.
I chalk this new New Message up to perhaps the same lofty levels of
experience that Mr Dymitruk may well have.
Then again, it's hard to get past messages like " TDD
offers little if you have your design in front of you" and feel gracious
at all.
Regards,
Jeff
|
| Jeff Langr / Langr Software
Solutions, Inc.?????
|
| ?+1-719-287-4335
|
|
|
|
J. B. Rainsberger wrote on 5/21/20 5:57 PM:
toggle quoted message
Show quoted text
Hi, folks.
Adam Dymitruk
wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events,
instead", but I otherwise trust him, so I'd like to know whether you
folks have any experience mixing event modeling with TDD.
I
don't, but I can see how I'd do it, and I imagine people who practise
TDD will eventually (eventually!) see the benefits of event modeling as a
shortcut. Adam and I have made vague plans to discuss this in some
detail, but if you folks have anything to say on the topic, I'd enjoy
reading it. -- J. B. (Joe)
Rainsberger :: ::
::
|
Re: Event Modeling and TDD... somewhat
:)
This has the same logic as "Don't do TDD, have lunch instead!"
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Re: Event Modeling and TDD... somewhat
Like Ron, I didn't find much content in that posting, so I went searching and found It's got more words, but not a lot of clarity.
I'm an old hand (since ~1980) of using event-driven state machines, implemented in a number of ways. They're great for isolating the activity in different states. I would not try to express all of the behavior of a system in one state variable, though.
Perhaps someone can walk me through this, but I see a lot of alternate potential state transitions that aren't represented in Also, I don't understand why a manager needs to "add a room" as part of the booking process. What happens if "Check In" occurs before "Room Readied?" It also appears that the guest is "Checked Out" everytime they stray outside the hotel's geofence. Et cetera, et cetera. This example both takes a naive view of hotel systems, and does a poor job of communicating what is event modeling to me.
I'm used to state machine programming simplifying things, not mixing them together. I would expect separate state machines for the booking and the room. The same events could be sent to both, though there would be a lot of "don't care" handling. (And I would still likely TDD the event handlers.)
So, please, someone tell me how event modeling is intended to be different from event-driven state machines.
- George
toggle quoted message
Show quoted text
On 5/21/20 7:57 PM, J. B. Rainsberger wrote: Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it.
--
J. B. (Joe) Rainsberger :: :: ::
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Re: Event Modeling and TDD... somewhat
This has the same logic as "Don't do TDD, have lunch instead!"
Fortunately, it's not a forced choice.
Charlie
toggle quoted message
Show quoted text
On Thu, May 21, 2020 at 4:57 PM J. B. Rainsberger <jbrains762@...> wrote:
Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it.
--
J. B. (Joe) Rainsberger :: :: ::
|
Re: Event Modeling and TDD... somewhat
I've built event sourced systems, and TDD was very useful, allowing us to evolve our models as our understanding of the business grew, as our software exposed things about the business that had not been obvious before, and as the functionality?of the software had to change to meet new business needs.? Event modelling / event sourcing is a useful?tool (but with its own challenges) but it isn't a crystal ball, and you always have to consider the opportunity cost of spending more time on analysis and modelling vs getting software out into the field, getting it working, and getting feedback from its use.
On Fri, 22 May 2020 at 00:57, J. B. Rainsberger < jbrains762@...> wrote: Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it. -- J. B. (Joe) Rainsberger :: :: ::
|
Re: Event Modeling and TDD... somewhat
Yes, and ... if we were actually perfect designers. the code tells us things about the design.
If only we actually knew everything about what the software?would have to do to work in the user's reality before we built the software, then designing it right in the first place would work?beautifully.? Is that flawed assumption not the essence of why waterfall fails as a general approach to software development???
Ron Jeffries
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana
|
Re: Event Modeling and TDD... somewhat
I agree with Ron.
If only we actually knew everything about what the software?would have to do to work in the user's reality before we built the software, then designing it right in the first place would work?beautifully.? Is that flawed assumption not the essence of why waterfall fails as a general approach to software development???
In 30+ years of practice, the only times I have not encountered miscommunications, misunderstandings or misconceptions about what users wanted and needed were in the development of formal systems like compilers.? This is why we need feedback on working software to discover misunderstandings and the flexibility to rapidly adapt to those discoveries. Being tied to a formal model radically increases the cost of change.? If the code is the model, I have found no better way than TDD to iteratively deliver slices of working software, get concrete feedback, and adapt the code to address that feedback.
It seems to me unlikely that event modeling, even if it were applicable everywhere TDD is applicable, was able to find and correct all the problems that TDD finds and corrects.
I think the style of that posting is indeed unfortunate, ell-advised, and likely misleading and quite possibly wrong.
Aside from that it didn't have much content.
:)
R On May 21, 2020, at 7:57 PM, J. B. Rainsberger < jbrains762@...> wrote:
Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it. -- J. B. (Joe) Rainsberger :: :: ::
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Re: Event Modeling and TDD... somewhat
It seems to me unlikely that event modeling, even if it were applicable everywhere TDD is applicable, was able to find and correct all the problems that TDD finds and corrects.
I think the style of that posting is indeed unfortunate, ell-advised, and likely misleading and quite possibly wrong.
Aside from that it didn't have much content.
:)
R On May 21, 2020, at 7:57 PM, J. B. Rainsberger < jbrains762@...> wrote:
Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it. -- J. B. (Joe) Rainsberger :: :: ::
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Event Modeling and TDD... somewhat
Hi, folks.
Adam Dymitruk wrote this on LinkedIn.
I don't like that he framed this as "Don't do TDD; model events, instead", but I otherwise trust him, so I'd like to know whether you folks have any experience mixing event modeling with TDD.
I don't, but I can see how I'd do it, and I imagine people who practise TDD will eventually (eventually!) see the benefits of event modeling as a shortcut. Adam and I have made vague plans to discuss this in some detail, but if you folks have anything to say on the topic, I'd enjoy reading it. -- J. B. (Joe) Rainsberger :: :: ::
|
Re: Tests “scoped” to implementation
Hey
During interview i explicitly asked: - what should be the output when input array is empty - can input array hold only a particular subset of Ints (like non-negative only) - is input array sorted.
And the responses were: - for an empty input array, output shall be true only and only if given number is 0 (and false in other case) - input array can hold any arbitrary ints (positive, negative and zero) -?input array is NOT sorted?
I asked for "expected" algorithm at the very end of interview and I was told: "sort input array and use 2 pointers".? Given i knew "expected" algorithm from the very beginning and use TDD to implement it _could_ drive me to different tests from these i did for my naive solution - moving 2 pointers on sorted array requires a different set of tests (like boundary conditions)? which are "specific" to this algorithm.? What do you think?
br JM
On Sun, 16 Feb 2020 at 18:43, J. B. Rainsberger < jbrains762@...> wrote:
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.? A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example? Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true? [1,2,3] and 5 ? ? ? true? [1,2,3] and 4 ? ? ? ? true? [1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.? Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ?? I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases... What do you think ? Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information.
Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite.
Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily.
When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.?
I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.?
Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.?
J. B. Rainsberger :: | |
|
Re: Tests “scoped” to implementation
There was a function named "updateSubscription" which was used to set a "newSubscription" which was then returned.?? Inside the very large function was a line which read "validation = isValid(<long list of conditions>);" this was untyped TypeScript. Then later it read "if (validation) {isInvalid = false; return validation}"
I had thought that validation was a boolean and refactored out the logic before calling the function. But validation was actually an http response object. Hide quoted text On Mon, Feb 17, 2020, 01:40 A. Lester Buck III < buck@...> wrote:
Well that is just torturing us TDD newbies....
Can you share examples on the list?? What does it mean for a function or
idiom to lie about what they are doing in non-obvious ways?
Thanks!
Lester
On Sun, Feb 16, 2020, 23:46 Russell Gold < russ@...> wrote: Massively agree. With legacy tests, I usually try to start with discovery tests - that is, I take my best guess at what the code is doing and write tests to see if I am right.?
Of course, that doesn’t mean that it is what the author’s *wanted* the code to do, but it the best approximation I have. That way, at least I can minimize the chances of breaking current behavior unintentionally.?
The most frustrating part is when this legacy code was written just six months prior...
----------------- Author,?Getting Started with Apache Maven <> Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don’t know what you’re missing!
On Feb 16, 2020, at 1:12 PM, Avi Kessner < akessner@...> wrote:
Lately, while helping with some legacy code, I've been finding that my "safe refactorings" aren't quite as safe as I wanted them to be, and that if I had started with the complete test first, I would have saved myself 10 minutes of thinking in the wrong?direction. Especially when functions or idioms lie about what they are doing in non obvious ways.
Always good to test assumptions. :)
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.? A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example? Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true? [1,2,3] and 5 ? ? ? true? [1,2,3] and 4 ? ? ? ? true? [1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.? Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ?? I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases... What do you think ? Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information.
Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite.
Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily.
When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.?
I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.?
Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.?
J. B. Rainsberger ::??|??|?
|
Re: Tests “scoped” to implementation
Massively agree. With legacy tests, I usually try to start with discovery tests - that is, I take my best guess at what the code is doing and write tests to see if I am right.?
Of course, that doesn’t mean that it is what the author’s *wanted* the code to do, but it the best approximation I have. That way, at least I can minimize the chances of breaking current behavior unintentionally.?
The most frustrating part is when this legacy code was written just six months prior...
----------------- Author,?Getting Started with Apache Maven <> Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don’t know what you’re missing!
toggle quoted message
Show quoted text
On Feb 16, 2020, at 1:12 PM, Avi Kessner < akessner@...> wrote:
Lately, while helping with some legacy code, I've been finding that my "safe refactorings" aren't quite as safe as I wanted them to be, and that if I had started with the complete test first, I would have saved myself 10 minutes of thinking in the wrong?direction. Especially when functions or idioms lie about what they are doing in non obvious ways.
Always good to test assumptions. :)
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.? A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example? Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true? [1,2,3] and 5 ? ? ? true? [1,2,3] and 4 ? ? ? ? true? [1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.? Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ?? I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases... What do you think ? Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information.
Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite.
Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily.
When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.?
I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.?
Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.?
J. B. Rainsberger ::??|??|?
|
Re: Tests “scoped” to implementation
Lately, while helping with some legacy code, I've been finding that my "safe refactorings" aren't quite as safe as I wanted them to be, and that if I had started with the complete test first, I would have saved myself 10 minutes of thinking in the wrong?direction. Especially when functions or idioms lie about what they are doing in non obvious ways.
Always good to test assumptions. :)
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.? A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example? Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true? [1,2,3] and 5 ? ? ? true? [1,2,3] and 4 ? ? ? ? true? [1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.? Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ?? I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases... What do you think ? Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information.
Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite.
Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily.
When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.?
I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.?
Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.?
J. B. Rainsberger :: | |
|
Re: Tests “scoped” to implementation
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.? A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example? Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true? [1,2,3] and 5 ? ? ? true? [1,2,3] and 4 ? ? ? ? true? [1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.? Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ?? I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases... What do you think ? Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information.
Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite.
Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily.
When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.?
I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.?
Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.?
J. B. Rainsberger :: | |
|
Re: Tests “scoped” to implementation
Anytime I write a test that passes first, I
consider:
* Was the code so unclear I wasn't sure whether it'd pass? (Often the
design--both prod & test--warrants improvement in this case.) Does
this test give me confidence I wouldn't otherwise have?
* Do I sense it's a constraint that someone in the future might likely
break, particularly given the way things are coded?
* Does it document something important or otherwise useful about the
system, something not easily gleaned from the other tests? If I pull up a
list of all the test names, does this one add anything to the story?
If any of these hold true, I'll keep the test around for now... as long
as it's also a legitimate test! (I always watch the damn thing fail at
least once, regardless of whether it passed at the outset.)
Jeff
|
| Jeff Langr / Langr Software
Solutions, Inc.???
|
| ?+1-719-287-4335
|
|
|
|
Russell Gold wrote on 1/16/20 5:54 AM:
toggle quoted message
Show quoted text
I don’t understand the idea that they are noise. If they confirm desired
behavior, having them seems a plus. So why would you feel a need to
remove them?
Thx Ron. Actually I added more tests as requested by
interviewer but at the moment I saw then all passing I deleted them as I
consider them as a noise and redundant code ( given I stick to my
solution)?
P.s I
didn’t get the job as my rejection ?to add more ( wasteful ) tests made
me “hard to manage” in his eyes? I
don't see anything wrong with adding tests to confirm things. A common
case is when someone says "I think that breaks when ...". The ideal
response, in my view, is just to add the test and run them. Let the
computer decide.
As for
adding tests in case of refactoring, that seems speculative to me and
therefore probably wasteful. In an interview situation, of course, it's a
question of how badly one wants the job offer.?
But there's nothing wrong with writing an
additional test in response to a concern or question or doubt.
R
I
had a live coding interview yesterday and I faced interesting ( at least
for me) issue.? A
small background: I was about to implement a function ?to figure out if
sum of any 2 elements in input array is equal to given number. Example? Input. ? ?
? ? ? ? ? Output?
[1,2]
and 3 ? ? true? [1,2,3]
and 5 ? ? ? true? [1,2,3]
and 4 ? ? ? ? true? [1,2,3]
and 6 ? ? ? ?False?
As
I was constrainted by time (~ 25 mins) I started with TDD but decided
to skip most of micro steps.? In the end I implemented something pretty
naive ( with O(n^2) complexity - comparing sum of all possible pairs)
but it wasn’t highly welcome by interviewer.? Moreover my interviewer
wanted ?me to add extra test cases ?( beside the ones which brought me
to my solution - as shown above ) just in case when” in future you want
to refactor an existing solution to something more sophisticated”. I
strongly refused as these tests will not make any sense from TDD point
of view: they will all immediately pass.?
Do you
believe that adding extra tests cases “for future refactoring” makes
sense ?? I
can imagine that for a particular solution of this task ( algorithm
being sorting input list + using 2 pointers) If I go strictly with TDD (
a new test case must first fail) a new solution would ( but does t need
to ) require a different test cases... What do you think ? Is it
possible that TDD is not a good fit for strong “algorithmic tasks” ?
Ron Jeffries
It was
important to me that we accumulate the learnings about the application
over time by modifying the program to look as if we had known what we
were doing all along. -- Ward Cunningham
|
Re: Tests “scoped” to implementation
Hi Steve,
I understand the sentiment and I agree with you from a production code?perspective, however the interview may be trying to understand if you understand patterns at all, and you're not helping them by refusing to even try.? I mean, in a typical?programming interview we write a bit of code that nobody needs to solve a problem that nobody has, eg fizz buzz.? Just for the sake of showing that I can, I would do it.? I would also add that in real work, I would wait for the time when using a patterns simplifies the code, rather than complicate it.
TDD is a great technique, but does not constitute all of software development.? Just because writing a test that succeeds without writing any additional code may not be a step in TDD does not mean that such tests cannot serve useful software development?purposes.
Where I tend to quarrel with interviewers is that I firmly believe?in not imposing design patterns until?they emerge in the code, which does not tend to happen until there are additional requirements that motivate reuse.? Many interviewers request speculative design patterns that I resist on principle.? It has cost me more than a few jobs.
On Thu, 16 Jan 2020 at 16:57, Russell Gold < russ@...> wrote: =
I'd add the test because it would require reasoning about the specific code to decide whether it would (probably) run.
Suppose we implemented it with a hash table, for example :)
And that's my point. An order or particular?test cases you wanna have depends (or can depend) on your implementation. If you go for a particular?solution, like Hashtable or do sth else it can simply drive you to write a new test case which shall fail first. I thought that idea of TDD (at least how it was defined by Uncle Bob) is to add a new failing test that would force you to change implementation of your SUT, and not simply repeat what is already done…?
That depends; if you have known requirements, it makes sense to add unit tests to confirm the corresponding behavior, even if they pass when you write them, as you might change your implementation later and any requirements you forget to test for now could easily be forgotten. The fact that your current implementation happens to pass those tests doesn’t make them superfluous.
Of course you can as nothing prevents you from doing it. In the simplified case i already provided above, what other cases can you add to express the requirement??
I believe that working in micro steps of TDD would allow (in majority cases) to express all requirements as test cases... and other tests would be simply redundant as they will simply duplicate existing test/tests.? In my case by adding all possible tests - for empty array - array with 1 element - array with 2 elements -? summing #1 with #2, #1 with #3 and #2 with #3 for array with 3 elements? and getting to the solution with double/nested loop i can not see any point of adding more tests for my existing implementation. If my implementation would be more sophisticated than I could probably have more/different test cases but for the existing solution i believe it covers all possible options (i am not talking about property-based testing)
br JM
?
br JM ?
R On Jan 16, 2020, at 7:25 AM, Rene Wiersma via Groups.Io < R.wiersma@...> wrote:
Purely from a TDD point of view it is not necessary to write a test for the last case, as we would not have to add or change any existing code to make it pass. However, in this case I would add the test for completeness sake, and future reference.
Ron Jeffries
The seemingly easy way of learning — by asking — is not necessarily the best. When you eventually understand, you will understand fully. — Dragon ? ?The Line War ? ?(Neal Asher)
|
Re: In Israel Soon? Speak at CD/CP Israel meetup.
Needless to say - if you are on this list and live in israel - you're also welcome to speak on things you're passionate about in the realm of CD/XP.
On Sun, Jan 19, 2020 at 12:14 PM Roy Osherove via Groups.Io <roy= [email protected]> wrote: Hey all. If anyone on this list is making?their way to Israel soon, i'd love to host you at the CD/XP Israel meetup group. Ping me!?
--
|
In Israel Soon? Speak at CD/CP Israel meetup.
Hey all. If anyone on this list is making?their way to Israel soon, i'd love to host you at the CD/XP Israel meetup group. Ping me!?
--
|
Re: Tests “scoped” to implementation
Steve Gordon wrote on 1/16/20 9:31 AM: Where I tend to quarrel with interviewers is that I firmly believe?in not imposing design patterns until?they emerge in the code, which does not tend to happen until there are additional requirements that motivate reuse.? Many interviewers request speculative design patterns that I resist on principle.? It has cost me more than a few jobs. You probably didn't want those jobs. :-) Jeff
|
