¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Nmock domain
I have nmock.org which is about to be expire. I¡¯ve been paying for it for some time. as far as I can tell, the project is dead as is sourceforge where it points. is there anyone with just cause
By Steve Freeman · #36282 ·
Re: Classifying tests: problem? solution? something else?
Wisdom, for me, includes no longer viewing such usage as "improper", but merely something more like "unexpected" or "different". I don't even mean that we stop calling it improper, but that we stop
By J. B. Rainsberger · #36281 ·
Re: "The design signals are weak"
[email protected]> wrote: I believe I understand you better now. Indeed, I consider the signals "weak" in the same way, but then I change my expectation from "This code needs to tell me when a
By J. B. Rainsberger · #36280 ·
Re: Classifying tests: problem? solution? something else?
David, I got a few lumps on the noggin learning that. - George -- ---------------------------------------------------------------------- * George Dinwiddie *
By George Dinwiddie · #36279 ·
Re: Classifying tests: problem? solution? something else?
That is some WIZE advice¡­. Wish I could have heard it 20 yrs ago¡­. I¡¯d not have banged mine head so much and raged against the improper use of a term!
By David Koontz · #36278 ·
Re: Classifying tests: problem? solution? something else?
I've often worked with (and in) organizations where the perfect word (from my point of view) for a concept was already in use for something else. I've found that it useless to try to change existing
By George Dinwiddie · #36277 ·
Re: Classifying tests: problem? solution? something else?
In the context of software development, a customer test refers to a specification of a single thing that the people paying for the software want the software to do in the form of an executable
By Steve Gordon · #36276 ·
Re: Classifying tests: problem? solution? something else?
I like examples. WRT naming, I worked at an insurance company. There were problems with churn in API code, particularly around certain domain concepts. One of those was 'customer'. To the policy
By Sleepyfox · #36275 ·
Re: Which comes first: design skill or TDD?
"I don't know where people are learning this, apart from generic "life lessons" of perfectionism drilled into them when they were very young." I left university teaching about 15 years ago, but I
By Steve Gordon · #36274 ·
Re: "The design signals are weak"
Yes, the code I just wrote may be using some value that "seems wrong" for the class to own, and I may need to extract it to some place where it better belongs. I might have just introduced that value
By George Dinwiddie · #36273 ·
Re: Which comes first: design skill or TDD?
On 7/26/23 9:25 AM, J. B. Rainsberger wrote: > On Wed, Jul 19, 2023 at 3:55?PM Vaughn Cato via groups.io <http://groups.io> <vaughn_cato@... <mailto:[email protected]>> wrote: >
By George Dinwiddie · #36272 ·
Re: "The design signals are weak"
I find the terms weak and strong to be useful in a philosophical context, rather than a judgemental one. I e. Something is strong if it always results in a specific outcome , and something is weak if
By Avi Kessner · #36271 ·
Re: "The design signals are weak"
When I talk about a signal being weak, I mean that it isn't a strong indication that something must be done to correct it. The term "smell", I believe, was created to try to indicate that it's
By Vaughn Cato · #36270 ·
Re: Classifying tests: problem? solution? something else?
That's one usually-quite-important axis. :) It's one of the ones I continue to consider regularly. -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca <https://www.jbrains.ca>
By J. B. Rainsberger · #36269 ·
Re: Classifying tests: problem? solution? something else?
wrote: It might be wise to have a common vocabulary among such a large project community, but I definitely don't recommend One Corporation-Wide Strategy. :)
By J. B. Rainsberger · #36268 ·
Re: Classifying tests: problem? solution? something else?
wrote: I'd like to second this loudly: I noticed a huge improvement in my relationships with people when I stopped insisting on my understanding of the terms and instead focused on exploring the
By J. B. Rainsberger · #36267 ·
Re: "The design signals are weak"
wrote: I presume you notice the signal to consider refactoring coming from both the production code itself (most likely focused on the code you just added) and from the tests (most likely the tests
By J. B. Rainsberger · #36266 ·
Re: "The design signals are weak"
Interesting! I advocate becoming comfortable refactoring away from patterns, because many programmers still feel subtle cues of guilt or shame related to undoing design decisions, especially "bigger"
By J. B. Rainsberger · #36265 ·
Re: "The design signals are weak"
wrote: Cute. I love it. This captures very well how I try to teach the technique: as a change in or a difference in v
By J. B. Rainsberger · #36264 ·
Re: "The design signals are weak"
Indeed. I'm not a fan of the Transformation Priority Premise as it seems to me to have been advertised, even though I imagine I have a similar priority tree of heuristics in my mind when I think about
By J. B. Rainsberger · #36263 ·