开云体育

Josue - thanks this a gem. Since Jeff is on this (I think) we can just ask him to update his book for my daughter. Jeff - Thanks in advance for updating your book for a 16yr :-) Cheers Mark

For Java: Agile Java: Crafting Code with Test-Driven Development - Jeff Langr <https://www.amazon.com.br/Jeff-Langr/e/B001IR1BYI/ref=dp_byline_cont_book_1> It is the one that I indicate when they

Personally, I tried very hard to work with TDD within the Actionscript community, but I was never able to find a job where the team I joined already did TDD. When flash stopped being a viable career,

Hi Dan! Good to see you here! I would recommend connecting with Jon Reid if you haven't already, he is sharing a lot about TDD on iOS. Here are some links: twitter -> @qcoding mastodon ->

Perfect, Thank you again for the wise words Charlie. Really appreciate it! I will continue my journey, I know how to find a job and I will continue putting myself out there writing about TDD and how

Hi Dan, That's why I added the provision that it might be harder these days. Some of us have been around a fairly long time, so you might need a time machine. :-) But I still think it's important to

Interesting thank you so much Charlie!, May I ask how you ended up these teams? I'd love to be part in a XP even XPish team. P.D. Jon Reid invited me to this group and I'm very glad and honour to

Hi Dan, None of us can tell you what you _should_ do, but we can tell you what has worked for us. :-) For me, I've been happiest doing work that I like, in the way that I like. That ended up being

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

Possibly that is why in XP we called them programmer tests and customer tests. :) Ron Jeffries ronjeffries.com <http://ronjeffries.com/> If it is more than you need, it is waste. -- Andy Seidl

Rather than categorical classification, perhaps it is useful to think of "axes" of test strategy (plural of "axis", not "axe"): The main ones in my mind are... 1. Collaboration: How many production

I see those as: 1) tests that ensure that the code does what the developers intend it to do, and 2) tests that ensure that the code does what the users expect it to do.

I'm a bear of little brain. There are tests that are fast & good enough to support refactoring (only, maybe): you can happily run them after renaming a variable. There are tests that show that the

Freedom to focus on one thing at a time. - what am I building? - what defines success--how will I know when the code works? - how do I describe that? how will I interface with that? - how do I code

I have similar ideas. Classifying tests in terms of where in the pipeline they are most helpful in terms of ensuring quality makes most sense to me. That classification would be something like

Totally worth you Maurício there. Having been responsible (inherited) for a 40 min test suite on an app worked on by hundreds of devs: determinism and cost were high on my priority list. Fox ---

My feeling is that we over-promise a bit on the feedback loops. Automated mistake detectors provide a pretty strong signal in the event of a "refactoring" that instead moves one or more measurements

In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to “care less” about semantically

I’d actually say TDD doesn’t TEACH much. It helps reinforce teachings you should know. — Charlie 73 de KG2V Http://www.thegallos.com

Refactoring is an essential part of TDD, wouldn’t you say? And how can you refactor if you cannot recognize code smells that indicate that the code is not clean?