开云体育

Hi everyone, I'm running into a scenario where I need to add extra condition in sql statement like this sqlStatement.sql("select id from table_a") if (conditionA == true) { sqlStatement.sql("AND table_a.column_a == 0") } // note there's many similar sqlStatement changes per other conditions as above.... The good news is that there's a good amount of integration tests surround this area. However, I feel like it's very rigid to make changes to sql statement based on some business conditions. The other option I can think of is basically to move the condition to a higher level and then it's probably easier to unit test to check the code to execute different SQL statement based on the condition. Although I gotta say, the easiest change (least amount of effort is to make the above change and write integration tests for that change) Moving the business condition to higher level is possible, but I would have more works to break some more dependencies and keeping the existing API unchanged as there're lots of methods calling this method. Any thoughts/comments/suggestions? Cheers, Tony

Help an old timer out... I don't know why this does NOT work... I want to redefine the subscript method... in Swift ... var str = "Hello, playground" // https://docs.swift.org/swift-book/LanguageGuide/Extensions.html // Extensions can add new subscripts to an existing type. class Inning { var array = ["first", "second", "third", "fourth", "fifth", "sixth", "seventh", "eighth", "ninth"] } let inning = Inning() print ("\(inning.array[1]) inning") // prints "second inning" extension Array { subscript(digitIndex: Int) -> Int { let decimalBase = 1 return digitIndex - decimalBase } } //print("\(Inning[1]) inning") let x = inning.array[1] print ("\(x) inning") // expect first inning via use of extension Much like the document does here: Subscripts Extensions can add new subscripts to an existing type. This example adds an integer subscript to Swift’s built-in Int type. This subscript [n] returns the decimal digit n places in from the right of the number: 123456789[0] returns 9 123456789[1] returns 8 …and so on: extension Int { subscript(digitIndex: Int) -> Int { var decimalBase = 1 for _ in 0..<digitIndex { decimalBase *= 10 } return (self / decimalBase) % 10 } } 746381295[0] // returns 5 746381295[1] // returns 9 746381295[2] // returns 2 746381295[8] // returns 7

Has anyone of us used the XCFit BDD framework? https://dzone.com/articles/xcfit-full-stack-bdd-for-swift-using-xcui-cucumber I've not opened the can on this set of tools... wonder if you all have advice to give? Years ago I learned and used a mash-up of Fitness & Selenium called StoryTest-IQ ( https://sourceforge.net/p/storytestiq/wiki/Home/ ) we called it a custom DSL and it worked well for a while - became a bit of a chore to keep all the Acceptance Level test functioning as the code under test mutated with various additions. Oh the good old days - when Java was king and the world could still talk on a port that wasn't port 80 or 8080. What does the term cucumberish mean?

I’ve been pondering for a few days about this. Asked a knowledgeable colleague and still wondering. https://docs.swift.org/swift-book/LanguageGuide/Extensions.html Swift has this awesomeness called an Extension. it is not exactly OO inherentness but it’s close. Maybe as close as X = X * X is a power. I’m thinking it is a Open/Closed abiding Inheritance- What do you think?

Hello folks, I just came across this Groups.io - thanks JB. Since the best TDD minds in the Universe are here maybe I can get some help learning... My area of study these last few months has been Swift for iOS Apps. I've written lots of example code - but that only takes your learning so far (and it's not far enough!) - so I ventured beyond tutorials and wrote an App for some colleagues and published in the Apple Store. Now that required lots of learning that is not in the tutorials. See InspireMe! Cards - Real Advice for Agilists https://www.inspiremecards.app I wrote that App without any automated test. Decided that was NOT the way to go in the future. So I needed to dust off the old Java TDD skills and apply to Swift. Xcode has wonderful integration for unit testing & even UI testing & performance testing. A card flipping App doesn't have much business logic nor Obj model - but has lots of views in the SwiftUI world. So testing the View layer is the primary need. Trying to learn the UI testing layer inside of Xcode is very difficult... can't seem to find much documentation. All the examples of course WORK... but my attempts do not... so learning from "canned examples" is not fruitful. I was invited to James Greening's TDD course ( https://wingman-sw.com ) and jumped at that opportunity - he's a rock star in the TDD community and I highly recommend his awesome TDD course. Even if you are NOT an embedded C/C++ programmer you will learn lots from James. And to get a glimpse at his work flow - well it is MIND-BLOWING. Do not think you know what TDD is until you've seen a master in action... to generalize; YOU are taking WAY to BIG of a STEP! To solve this problem - I teamed up with the good folks at TDD.Academy and Lance Kind. He's mentoring me in TDD on Swift UI with iOS App dev on his Live Coding Stream TDD.Academy - shameless plug: https://www.twitch.tv/tddacademy/videos Yet I've still got many many questions. And I've learned lots in the last several months. I now consider my self a TDD beninnger and perhaps competent in SwiftUI Testing... which means I can spend hours banging my head on a testing of a simple iOS app and fix it the next day - Competent. So what have I learned: (maybe this is a good place for a list) - Doing TDD is way easier with a mentor (programming pair) - I still forget to write the test first. - Testing the Zero (NULL) case first - Using the Empty-Class pattern - Learning to craw - before I attempt to RUN. - Tons of Swift & SwiftUI stuff - SwiftUI toolbars don't play well with the testing ID accessibilityIdentifier() - so you can quit banging your head on this one - my head is flat. - UI tests are NOT fast... 3 orders of magnitude slower than a unit test. - You MUST speed this up... so you go get View Inspector ( https://github.com/nalexn/ViewInspector/blob/master/guide.md ) and learn to unit test the View layer. - Even View Inspector has problems with toolbars... so you go back to head banging... - Apple has a big war chest of money - and then are not spending it on programmer documentation - You need to know your View hierarchy - so in a test " print (app.debugDescription)" - is Your savior - You could try the dev tool - *Accessibility Inspector* - but you will return to the print statement. - You have to GROK the XCUI element query stuff... and no one will talk about it in the examples/tutorials - You guessed it Apple doesn't understand it so they did not document XCUI Element Query... - so something like *app.buttons["my_button"].tap()* might just poke your buttons I'm journaling my experiments and learning opportunities on The Swift Dojo ( https://www.theswiftdojo.com/home ) you are invited to come along with me.

Hi, folks. I've downloaded this group to the free plan on groups.io, so if you notice anything lost or broken as a result of this change, then please let me know. As far as I can tell, nothing important will be lost. -- J. B. (Joe) Rainsberger :: https://tdd.training :: http://www.jbrains.ca :: http://www.thecodewhisperer.com

I am currently working on what you could categorise as a workflow automation product. The product is comprised of independently deployed front and back end components. The core domain is realised by a single .Net Core solution. The front end interacts with it via a REST API and it interacts with further components (and occasionally itself) using messaging. Two core aspects of the internal design are Entity Framework for data access and extensive use of the mediator pattern. Using mediator, every element of the solution is broken down into sets of 3 classes, request, handler and result. Requests and results are POCOs whilst handlers implement behaviour and require few dependencies. Often, in cases where the only job to do is orchestrate the sending and receiving of requests and results, the sole dependency is the mediator type itself. Other requests fall into the two categories of query or command. All told a well thought out and pleasant stack to work in. Mediator leads to few dependencies, which in turn leads to simple classes that are easy to drive with tests. Except for the fact that nothing is ever quite as simple as one would like. There is a problem writing tests in this solution in that to test a simple isolated query the test setup must replay all the steps the application would theoretically take in order to reach the point whereby the query can return sensible results when issued against Entity Framework over an in memory database. This is achieved by gathering and then issuing a collection of steps, where each step is a high-level mediator message, as the “Given”s and “When”s of a test scenario. During the “Then” assertions are made against the result POCOs that were observed by a stub implementation of the mediator type, e.g. assert that the last created entity of type “A” should have such and such an “A.Name”. I believe the goal of the approach is to use the real application code to avoid making assumptions about the state of the system when writing tests, however the more steps required to reach a the prerequisite snapshot of state, the greater the reliance on developers writing new tests to comprehend the set of steps that should be replayed in order to reach the point from which they want to proceed. It feels to me as though what has gone wrong here is that although the application code has a nicely decoupled architecture the database and/or the Entity Framework domain model layer does not and as a result entities depend on other entities in a way that makes them intrinsically co-dependent. This interdependency is revealed by tests which cannot drive simple code without themselves being complicated. I thought perhaps I could lean on the experience in this group to gain some suggestions on how to reduce this kind of test friction? Paul

I just came across this blog post. The title is click bait. Overall I think the blog post is good and accurate. However, the comments scare me. What are your thoughts? https://medium.com/madhash/rip-tdd-or-are-we-just-thinking-about-it-wrong-32ef36b9c5

Hi, folks. Adam Dymitruk wrote this on LinkedIn. https://www.linkedin.com/feed/update/urn:li:activity:6668371835337490432/ 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 :: https://tdd.training :: http://www.jbrains.ca :: http://www.thecodewhisperer.com

This week there have been two interesting TDD webinars about why after 20 years it doesn't dominate the software development scene. To tell the truth, in some situations, it is even an unknown technique and therefore not adopted not by choice but out of ignorance. My personal feeling (I have been in the software development field since 1995 and met extreme programming in 2001) is that in the last 20 years, starting from the rise of agile methodologies, there has been a clear bifurcation: on the one hand, craftmanship, extreme programming, people who apply to their profession that continuous improvement we preach. On the other hand, people who have learned from their predecessors (someone like me, possible), perhaps losing something, as if the transition between anticipatory and evolutionary design had been missing. We missed the design at all. Now my question is: how can we recover? It looks like a chicken egg problem. In the past a programmer learned design principles and techniques and then applied them (with all the disadvantages we know) but the process was clear and straightforward. Today if I started from scratch, under expert guidance, I would probably learn to program and design using TDD. But if I am already a programmer, maybe for 10 years (iterating the same bad year ten times), who knows almost nothing about good design (or at least is not aware of it), could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?

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” ? Br JM --

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! -- Thanks, Roy Osherove http://osherove.com http://elasticleadership.com

Using Visual Studio, C#, Razor forms, nothing complicated, just POSTING and GETTING and updating form elements. Alan Baljeu alanbaljeu@...

Hi! I am happy to announce that I've recently published my second book on TDD in Spanish. Same title than the first one but completely new. With foreword by Sandro Mancuso. https://leanpub.com/tdd-en-castellano/ With code snippets in English and all the prose in Spanish. Using several programming languages and styles. Some more notes in Spanish over here: https://www.carlosble.com/2019/12/publicacion-de-mi-segundo-libro-diseno-agil-con-tdd-edicion-2020/ Thank you and happy new year :-)

Hello All, In case anyone is interested, here is a video in which Nat Pryce and I are doing a diamond kata at KotlinConf https://www.youtube.com/watch?v=I0OgA4OcXOY Regards, Dmitry

I would like to amplify Avi's comment below. I have noticed something when programmers try to practise TDD: they don't seem to learn how to refactor. I don't mean to state this so harshly, but it seems that they struggle a lot more with refactoring than I did when I started. I have this feeling that "we" learned relatively quickly compared to what I see, even comparing myself programming in Java in 1999-2002 to today's programmer also working with Java. And today's Java programmers have better libraries and better tools! They use IDEA and Vavr, but I had Eclipse and plain Java. :) I'd like to know your impressions. Which kinds of problems do people have when they try to learn how to refactor? When they learn how to guide a design to evolve? Why does it seem like they have more difficulty learning this than "we" had? I admit that I probably have some strong cognitive distortion. That's why I'm asking this question. Cheers, -- J. B. (Joe) Rainsberger :: https://tdd.training :: http://www.jbrains.ca :: http://www.thecodewhisperer.com ---------- Forwarded message --------- From: Avi Kessner <akessner@...> Date: Thu, Nov 14, 2019 at 5:05 AM Subject: Re: [testdrivendevelopment] We are back on the air! To: <[email protected]> Is this the diagram you wanted to share? https://osherove.com/blog/2019/11/12/an-updated-diagram-of-the-tdd-process-from-the-upcoming-3rd-edition-of-art-of-unit-testing I would recommend making a box which is part of the flow rather than some external dotted lines. For example, maybe the box should read, " Apply SOLID principles" as part of the refactoring, and then before the next failing test have something like, "design the contract" I think the community needs more explicit direction on the design being done in those phases.

Hello, folks! We are back. Maybe you weren't expecting this email, but here it is. This group is back as a web resource, safe from whatever Yahoo! plans to do with the content. I hope it continues to help you. I intend to bring some of the conversations happening on social media into this group, in part to make it easier to expand in longer form on the ideas and in part to make them easier for you to follow and participate. You don't need to have been there when the conversation happened. I encourage you to do the same. I also intend to revive this group as a resource for the confused. If you need help with evolutionary design and/or TDD, then you can trust the answers here more than you can trust the answers "out there". The people here who want to answer you likely have more experience and care more about your success. At least I'd like to attract more of those people here. So there it is! I apologize for the momentary spike in messages as you adjust your email filters. I have to do the same. Enjoy! -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002

Hi, folks. We need moderators. Please volunteer! Your central responsibility involves approving new messages and new members. We will have a significant amount of old-new traffic for the next few weeks as people return to the group. I would prefer not to continue to act as the bottleneck. :) When a "new" member writes a not-obviously-horrible message for the first time, I approve the message and turn moderation off for them. I ban people who spam us. Mostly, that's it. Thanks! -- J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca Teaching evolutionary design and TDD since 2002