开云体育

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 who should have the domain? thx S

> I think the test name separation by unit test/integration test/micro test/behaviour test doesn't work, but I'm not sure what's the "sensible" way to separate them yet like fast/slow/io/non-io? business/technical?structure vs behaviour? I'm curious about this, because I hear it from time to time. I have some questions, and we don't have to limit those to Tony, although I'm also interested in his replies: 1. What kind of "doesn't work"? It works for me, so maybe we have different ideas about how it could work or should work. 2. I classify tests in order to better understand all the different kinds of intent and purpose we have when we write them. This helps me decide how to choose which tests to write next. What challenges do you have with all these test classifications? 3. Some people report that there are too many test classifications to understand well. They become confused. I empathize. Why don't you simply ignore those classifications until you need them? Finally, as for the difference between business and technical tests, when I talk about TDD I tend to focus on technical tests, because that's my context for TDD: to focus on the code. I handle Customer Tests (or business tests) quite differently, and I only sometimes practise what we've called Story-TDD or Acceptance-TDD. I practise it most often when I play the role of Customer for myself, such as on my volunteer projects. I try _very hard_ to clarify this for the people I teach, but I always run the risk that the message doesn't make it through.-- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

On Thu, Jul 6, 2023 at 2:19 AM <groups-io.20191212@...> wrote: But signals about design errors? My experience, and my survey of the literature, suggests those signals are actually pretty weak. The Koss/Martin bowling game exercise offers one candidate example, where a compiler error triggered a re-evaluation of the use of "value objects" in the API; you'll have to consider whether reverting to a general purpose data structure was a design improvement or not.... I find this pretty provocative, so of course, that interests me immediately. :) Two questions leap to mind: - What kind of "weak" is your "weak" here? - Which "survey literature" has drawn conclusions about the strength of design error signals? Most of the attempts I've seen have measured what happens when people who don't know much about design try to write tests first, notably undergraduate computer science students. To be clear, I routinely experience design signals that are relatively weak individually, but become stronger in aggregate, such as "I see 3 reasons to do refactoring X, so now I feel confident that doing it will help". I also notice that, as I become more experienced, I react to the signals more softly, meaning as suggestions or hints, rather than as urgent calls to action. I don't consider that a weakening of the signal, but rather an indication that I have become less dogmatic in my practice. To provide examples of how I think of "strong" or "weak", I can think of at least two common examples of design signals that I'd label "strong": - scattered duplication of behavior focused on a naked, primitive data type (a number or some text) which points towards introducing a Whole Value type - rampant duplication in application request handlers which points towards introducing Parsers and extracting Standard Workflows If you didn't know those options existed, I'd expect duplication in either production code or tests to provide the motivation to seek them out.-- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

I am surprised to encounter so many people who claim something like this: "You must understand how to design before you can practise TDD well." I say the following in response: - Practising TDD "poorly" still helps many programmers - One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well" - Your claim, framed that way, needlessly scares programmers away from TDD who need it Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think? -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

Here in the middle of 2023 we see an AI bubble in the stock market - launched by OpenAI's release of ChatGPT. One can not turn on an info feed without hearing about AI these days. It is hotter than... Crocks at the Beach in Boca Chica Texas. Have you used an AI assistant to do any Dev work? Have you used an AI assistant to help in TDD? ---- Have a look at this article and let me know if this helps learning/practicing Testing as a first class responsibility role of Developing. TDD with Copilot (on Medium) https://medium.com/@bellaposa/ios-and-copilot-e32a3a39e46b

I'd like to build on this in addition to echoing it. Everyone, feel invited to join in. I'm asking everyone and not only George. Which freedoms? Why do you care? What do those freedoms give you? I have noticed these kinds of freedom: - freedom from chasing after silly mistakes - freedom from having to "get it right" the first time - freedom from agonizing over design decisions - freedom from the blank page Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD. -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. On Mon, Jun 26, 2023 at 5:04 PM George Dinwiddie <lists@...> wrote: "That's what TDD is, you know. It's not just test cases and assertions and a suite and a test runner. That's what TDD needs. But what TDD is... is freedom." On 6/26/23 12:59 PM, George Dinwiddie wrote: > Joe, > > There are a lot of aspects I could mention, but it basically comes down > to the fact that TDD made my software development joyful. The worrisome > aspects were out of my head and into test code. > > - George > > On 6/26/23 9:21 AM, J. B. Rainsberger wrote: >> Hi, folks. Why do you still care about TDD? >> >> Please skip the platitudes and write from the heart. Why does it still >> matter to you? Why do you still practise it? How does it still help? >> Why do you still teach it? >> >> Or not? >> -- >> J. B. (Joe) Rainsberger :: tdd.training <https://tdd.training> :: >> jbrains.ca <https://www.jbrains.ca> :: >> blog.thecodewhisperer.com <https://blog.thecodewhisperer.com> >> > -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach https://pragprog.com/titles/gdestimate/ ---------------------------------------------------------------------- -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing more about TDD or continue the industry and write about iOS frameworks only. It's interesting because I really thought that reaching this point (where I can do TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore. Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream. Regards, Dan Torres

Hi, folks. Why do you still care about TDD? Please skip the platitudes and write from the heart. Why does it still matter to you? Why do you still practise it? How does it still help? Why do you still teach it? Or not? -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca <https://www.jbrains.ca> :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.

Tony raises some interesting points. It does seem to me that people have different ideas about these issues. My own preference is a simple division: “pure” unit tests that only simulate I/O and timers, on the one hand, and end-to-end tests that mimic the way a user or other subsystem would interact with the one we’re building. It’s not always possible to make such a division perfect, but I’ve had a lot of success with this approach. I don’t really understand the problem here. If you are only coding in response to failing tests, aren’t you generally forced to execute all code paths? I could see NPE’s etc. happening because we’re not perfect, of course. Nobody said it was always easy :) Can you provide some simple examples? My initial take is that this is what prototyping is for. Try the next thing, and when you understand it, delete the code you’ve just written and start writing unit tests to force you to put it back (or at least, as much of it as is actually required).Again, I’m not clear on what is being asked here. As far as I understand it, TDD is intended to drive business intent of the code, not the internal details or algorithms. Maybe examples would help here. It absolutely does require changing mindsets, and that is one of the biggest obstacles to getting people to do it. But I have found that suitably motivated developers will spend the effort to learn it when they see it succeeding, in terms of higher throughput and better quality. Do read Michael Feather’s “Working Effectively with Legacy Code.” I have relied on it multiple times to deal with mature codebases without tests. I’m convinced that both of these have answers - but I don’t think I understand the questions sufficiently. ----------------- Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com> Now blogging at <http://russgold.net/sw/> Have you listened to Edict Zero <https://edictzero.wordpress.com>? If not, you don’t know what you’re missing!

I'm posting this for the benefit of those who follow the group via the online groups.io interface rather than as a mailing list as some of us do.... or is it just me? :-) Groups.io makes it look like a forum rather than a mail list and allows you to edit a post. But if you do that, those who read it as a mail list get a new email each time. For example, I just got six copies of one post with minor changes, which is mildly annoying. So, if this applies to you, please be aware of what happens when you edit and don't unnecessary changes after you have sent the post. If you have something that is important to correct, please make all your changes at once rather than piecemeal. TIA for being considerate. :-) Charlie

Hi, folks. When we had the idea to rescue this group several years ago, I wondered what would happen, even though I had no concrete plan for it. The most I've done so far is lightly promote this group to my TDD training course participants. We seem to be in the grip of the Wiki Death Spiral: nobody writes here because nobody reads here because nobody writes here. No complaints, no blame, no shade; just facts. Now that Reddit is dying in a similar way that Twitter has been dying, I wonder whether the time is right for some kind of renaissance here. I think I'd enjoy that. I find the social media landscape too fragmented. The next generation of programmers doesn't have a clear place to get advice from knowledgeable and experienced practitioners. I hope they stumble upon this place. I know that I needed it when I was their age. I don't have any particular request nor any particular news to share, other than this vague hope. I might even pay more attention to this place myself. :) Cheers, -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca :: blog.thecodewhisperer.com Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

Avi, On 6/23/23 11:46 AM, Avi Kessner wrote: > I'm also currently working on platform work. > How do you use tdd in platform work? I'm struggling with it. Or do you > setup chaos engineering instead? Not having experience in that domain, I don't have a ready answer for you. I do think this might be a good place to explore the topic, though. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach https://pragprog.com/titles/gdestimate/ ----------------------------------------------------------------------

Hey everyone, Some months ago I asked for help in the group and some of you gently answered my survey; now the research paper is out! You can check the preprint here https://homepages.dcc.ufmg.br/~pcalais/papers/tdd-flow-icse-nier-2023.pdf And I will be glad to discuss future work and evolutions of what is discussed here. Merry Christmas, Pedro Calais

Hey folks, how are you? I am a member of a group of researchers interested in studying the impact of testing practices on developer's productivity and well-being. Our goal is to improve the software engineering community understanding on how and why practices such as unit testing and test-driven development are effective beyond the impact on code design. If you are willing to help, we have 12 quick questions to you! https://docs.google.com/forms/d/e/1FAIpQLSch3XZ3NJNB-ZUqJy9d9hEfP-HvCeC-seXuJ7RaaxBK4NsAUA/viewform Best, Pedro Computer Scientist P.hD. http://www.dcc.ufmg.br/~pcalais

I have a domain entity called a "Booking Window" that has a Start Date and End Date, and defines a period in which a Member can make a Booking. The business is a mobile car wash, and Members can book a wash every 14 days. I have a means of establishing the first Booking Window - at the point of the Member signing up. Now I feel like the next most useful function is one that finds all Booking Windows closing "today" and makes new ones. So I wrote a test like this (kinda pseudo coded) test("nothing to do when no booking windows at all", async () => { const client = stubGraphQlClientContainingNothing() const clock = new FixedClock(new Date()) const windows = await makeTodaysBookingWindows(client, clock) expect(windows).toHaveLength(0) }) and my function was just export async function makeTodaysBookingWindows(client: GraphQlClient, clock: Clock): Promise<BookingWindow[]> { return [] } Then I decided I needed a test of the case that had bookings, but none ending today: test("nothing to do when no booking windows end today", async () => { const client = stubGraphQlClientContaining(bookingWindowEnding(tomorrow())) const clock = new FixedClock(new Date()) const windows = await makeTodaysBookingWindows(client, clock) expect(windows).toHaveLength(0) }) and the same function implementation allowed this to pass. Now I decided I need to do a real case, of one Booking Window ending today: test("create a new booking window when one expires today", async () => { const client = stubGraphQlClientContaining(bookingWindowEnding(today())) const clock = new FixedClock(new Date()) const windows = await makeTodaysBookingWindows(client, clock) expect(windows).toHaveLength(1) expect(window[0].startDate).toBe(today()) expect(window[0].endDate).toBe(today() + 14 days) }) and that forced me to make some production code. Now I am left thinking, what next? The code I wrote to make the above test pass does not loop, so I need to cover the case where there are many Booking Windows ending today, so I write this: test("create a new booking window for every window ending today", async () => { const client = stubGraphQlClientContaining(bookingWindowEnding(today()), bookingWindowEnding(today())) const clock = new FixedClock(new Date()) const windows = await makeTodaysBookingWindows(client, clock) expect(windows).toHaveLength(2) expect(window[0].startDate).toBe(today()) expect(window[0].endDate).toBe(today() + 14 days) expect(window[1].startDate).toBe(today()) expect(window[1].endDate).toBe(today() + 14 days) }) Now I probably have the production function I need, but the "create a new booking window when one expires today" test case is now irrelevant, so I guess the right thing to do is remove it. Anyway, thats enough to communicate my approach to this function. It doesn't "feel" great, so I'd appreciate knowing how others would approach this. Thanks!

Hi, folks. I embarrassed myself in a Surviving Legacy Code training course recently by fumbling with Subclass to Test in front of a bunch of JavaScript programmers. It occurred to me that I don't know the object-based analog to this approach. I waved my hands a little, then thankfully, I ran the clock out without much of a resolution. I'd like to make it up to them and I need your help. What is the corresponding technique when working in a language with objects but not classes? In JavaScript, for example, how do I achieve the same effect of being able to create a "testable" (more-inspectable) object in my test with minimal changes to the legacy code object definition? In JavaScript, can I do the equivalent of making a property visible to "subclasses" without making it widely-visible to all legacy clients? Or should I think about it a different way? My goal is to make minimally-disruptive changes to the existing code, while adding tests for it that would support refactoring. I want the equivalent of overriding _this small part_ so that I can simulate/control it in order to test that other part of the same object. I feel like I'm missing something obvious, since I'm barely functionally literate in JavaScript. Thanks. J. B. Rainsberger :: https://www.jbrains.ca :: https://tdd.training :: https://experience.jbrains.ca -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

I'm a desktop software developer getting into web development, using C# at present. Also aiming to do Angular. I'm fishing for strategies, techniques, tools I should be using to test stuff. My current scenario is my application starts in a web browser, connects to my web server, requires the user to login (OAuth2) to a 3rd party service. After login, the main path is for the browser to pose queries to my server, which it fulfills by using this 3rd party. I can do all these things. My confusion comes trying to write unit tests, integration tests, etc. There is no user to login, so how does one get started? Beyond that, I'm not greatly familiar with web stack software and so the fashion of doing TDD is also unfamiliar to me. Can you guide me? Can you point me to a guide? Beyond NUnit, what do you recommend for testing my server?

So there is a new tool on the block that permits new approaches to software development. This is my first attempt at describing what can be done with it. Ultimately this will grow in a blog post and maybe training course. I'm working with the Mercurial Distributed Version Control System, which makes a lot of things a lot easier and simpler than git, but I believe nothing I say here cannot be emulated in git. Here is the documentation, but it's not needed to understand what I'm saying. https://www.mercurial-scm.org/doc/evolution/ The core idea is that changesets or commits to your version control system become mutable until you choose to publish them. You can split them, join them, reorder them, rebase them on top of other commits. Thus the "when" you do a change, becomes decoupled from "where" in the evolution sequence of the codebase. ie. You no longer have to make changes only at the end of an ever growing branch. You can make changes anywhere within your branch and at any time. Declaring a change "fit for public consumption" is decoupled from "committing to version control". This post is about what use you might make of this decoupling. Now keep in mind the definition of the word "Refactor". It means "Improving the code WITHOUT changing it's externally visible behaviour". If you refactor the code and a test breaks.... you are either not doing a refactoring or your tests are not just testing behaviour, but are coupled to implementation details. More on that later. Now in the game of TDD, you have a couple of moves you can make... Refactor a test. Extend a test. ie. Provide more test coverage of existing code Refactor the code. Change the Test to check for new behaviour. Change the code behaviour.. Add observability. (Logging, tracepoints etc.) Add inner checks (precondition asserts documenting my beliefs and assumptions about the code). Refactoring a test or extending a test should NOT require a change of code. If it does, something is wrong. Either it was not a refactoring or extension, or the extension uncovered a preexisting bug in the code. Number 6 is interesting and not usually mentioned in the context of TDD. It's sort of orthogonal to unit testing, in fact, unless it's a requirement like an audit trail, I'd explicitly strongly recommend you _don't_ unit test logging as it should NOT change the behaviour of the code whether it's turned on or off! However, as you will see later, it becomes a powerful additional tool in your armoury! The traditional mantra of TDD is never write a line of code unless you have a breaking test. Note that this imposes a timewise ordering on activities. Write a test. Watch it break. Implement the matching code. Watch it go green. Refactor. Keep it green. Now the point with changeset evolution is we don't care _when_ we do those things. We care about the order in the evolution of the codebase in which they occur. For example, implementing a change in behaviour of the code should result in a test breaking (the tests are verifying the behaviour). If it doesn't our tests are insufficient. We should extend our tests. Or conversely, if we write a test in anticipation of the next step, the implementation step, and it doesn't break, we again have something wrong. Furthermore, most of us are not sufficiently lucky to always and only work with a fully TDD'd codebase with excellent coverage. So when working with "legacy" code, there is a zeroth step... extend the test coverage. So how much coverage is "enough"? Must we first get 100% coverage of everything we touch? What are we testing? Mostly that it just does whatever it does which we barely have a clue about. The entire point of refactoring is to improve the internal qualities like readability, understandability and simplicity of the code. Conversely a bundle of code ridden with technical debt is obtuse, and odds on you don't really have a clue what it does. So how do you even start with a debt ridden legacy code? I start with observability. I turn on logging, I add logging, I run the code to get a clue. Commit! I then add a "Hello World" unit