开云体育

Sort of related - wrt documenting microservices, how do you feel about having a small number of (likely system) tests like this?: https://github.com/ben-biddington/richard_iii/blob/master/test/acceptance.tests/an_example.rb

It will definitely hurt less if you wrap the API, because then you can test your own code in isolation from it where it makes sense to do so. As far as tools go, ReSharper, NUnit, and SpecFlow are my favorites for test-driving C#, but it would probably be worth spending time researching what else is out there.

I've been away from serious OOP programming for a while, working in Prolog, etc. So now I'm back, using VS2013, and starting development with a large CAD API. My TDD experience has followed the old data-oriented style, testing whether a function causes the right kinds of objects to be produced, rather than testing that it invokes the right methods. (It makes more sense to me, that my concern is to construct the correct and very visible model, and not how that model was constructed.) So now, given this brand-new API (which I know is well made and stable), is it a good idea to create my own classes to wrap access to the API, or is it better just to access the API directly? Following the TDD mantra of test-first, I'm thinking about: { setup the test scenario. do something interesting. check what happened. } I write the above in natural fashion, and then build classes and methods to match that fashion, and link those to the underlying API. Does this all make sense? Shall I use the built-in test framework? Are there any valued innovations in the last years about software development? Alan Baljeu

Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote: Either approach you described can be justified. Test that just contains one variable is actually complete and says "the object can be constructed this way". Remember there is an implied "this does not fail" even if there are no asserts. In the classic cycle, you would then proceed to write another test, that tells a different story. Then, in the refactor phase, you'd maybe remove the first test. From my experience indeed sometimes you want to go so slow that this is useful. Other times not. In absence of gut feeling, do baby steps. Also, in non-strict typed languages (i.e. javascript) a test that just describes object construction syntax could be useful. A test is only wrong in case you have never seen it fail. All other tests are complete and functional. As for misleading, that depends how good a story the test tells. Tests can lie or drift apart from reality. Usually that is more likely when the test uses mocks. Michal

No. But I don't follow anything strictly! This varies greatly depending on what I'm working on/how comfortable I am with everything. When working with a new language/framework etc. my steps will usually be very small as I'm trying to figure things out as I go along. If I'm in vanilla Java doing things I've done before the steps will be bigger as I'm more comfortable. Kent described this in his book but referred to it as "gears" not steps See above + some gut feeling This is something I will let evolve as I add more tests. It seems like the pain your coworker was feeling could be down to not refactoring the test itself. Instantiating the class under test multiple times in a test is what I would consider to be duplication Yes, but only for a certain degree of "incomplete" :) You said "I disagree with the comment because it allows multiple unnecessary lines of code to be written and doesn't provide a progression that guarantees that all production code is effectively "tested"/covered.". I'd like to ask why you think this? Each of my tests are small and cover essentially at most one path through the code. -- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head. Something which you, I, and everyone else would call "Tuesday", of course.

Hi Kaleb, As others have said: Change gear depending on your experience wit TDD and comfort in the situation. There's a another point to be made though. Ron and Chet emphasized in their CSD training that TDD has two 'modes': design and implementation. When you write a new test, it usually introduces some sort of new concept in the system. You can write more than one line, even if the first line doesn't compile, if that helps you see what the interface/design should look like. When you have something you like, you make sure it compiles, but fails. Then you start with the implementation mode, and make it work. If there are more than one or two new concepts introduced in one test, I'd wonder if the test is maybe a little to broad in scope, and I should take a smaller steps. Wouter -- Wouter Lagerweij | wouter@... http://www.lagerweij.com | @wouterla linkedin.com/in/lagerweij | +31(0)6 28553506

Hi Kaleb, Regarding "an incomplete but green test is at best misleading and at worst wrong: if a test is green it should be a valid test, and a partial or incomplete test is not valid." ... If I think about using, say, a tool like Infinitest that is constantly running tests, it reports green against "incomplete" tests, and I'm ok with that. So I don't think it's "wrong" per se. I've both strictly followed the three laws and not. For me, it depends upon tools and problem at hand, as others have suggested. Mostly, I fix things that are obvious problems at the earliest possible opportunity rather than wait, but I'm not dogmatic about it. Jeff Langr Software Solutions, Inc. http://langrsoft.com Modern C++ Programming with TDD (http://pragprog.com/book/lotdd) Agile in a Flash (http://pragprog.com/book/olag) Agile Java: Crafting Code with Test-Driven Development (http://www.amazon.com/Agile-Java-Crafting-Test-Driven-Development/dp/0131482394)

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository. I have been confused by tests with names saying they check something that is not checked, making me spend time searching for problem in the wrong place. On the other hand during TDD it is rather important to know that the test actually fails, like you and others describe. The key as I see it is if the test is committed or not. Mostly the tests confusing me have come from being interupted while they happened to be green and then missing that they was not compete when coming back. Regards, //Samuel

Hi Kaleb, On Tue, Aug 26, 2014 at 4:48 PM, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] <testdrivendevelopment@...> wrote: Stop! Go back to where you had the empty test. Now, write the assert that matches the intent of the test. It (probably) won't compile, but at least you have the assert, and that's what drives everything else. Now fill in enough details so that the test compiles, etc. In general, if you think of a test as Arrange / Act / Assert, work backwards: Assert first, then Act, then Arrange. This is the TDD process in action /within/ the test. Cheers, Kevin -- http://xpsurgery.com -- remote one-to-one tutoring in TDD and OO http://kevinrutherford.co.uk -- software development coaching http://refactoringinruby.info -- Refactoring in Ruby, the book

Hi Kaleb, No, but when I get into trouble, I stop, back up and get more precise about how I'm proceeding. There should be no "typical" step size in your practice. Beck stressed the importance of learning to "shift gears" - to go at various speeds based on your needs at the moment. Sometimes you can move ahead successfully in big steps, sometimes you need to go slower. Practice both. Imagine if you decide to always move at a certain speed, without regard to the terrain. Either you would be moving at a ridiculously slow pace on the sidewalk or running down rocky hillsides. Either one could get you in trouble. A combination of what I'm doing - is it similar to something I've done before for example - and how I'm doing - how well are things moving along. When I go too fast - too big steps - things start to feel uncomfortable and I slow down. I define it with the parameters I know of and have available a the moment. Code is really easy to change and there's no reason to put everything in when I don't yet know for sure what I need or where I will get the parameters. No. Except in the sense that any test could be wrong. A test tests what it tests. You have to be aware of what you are testing and what you have not yet tested. No single test is "complete" in any meaninful sense of the word. Charlie

The official rules say to write a test, but only enough of a test to get a failure --- which means "not the whole test." But as to the title question: sometimes you should follow the rules strictly. Other times you might try not. http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd -- Tim Ottinger, Anzeneer, Industrial Logic ------------------------------------- http://www.industriallogic.com/ http://agileinaflash.com/ http://agileotter.blogspot.com/

Over the last three years I've been doing training on and advocating TDD where I work and a number of people have been striving to learn and use TDD in their daily development :). --- An experience with coworker 1 --- One of these coworkers recently published a 6-part series on TDD that starts off assuming no prior experience with TDD (https://www.simple-talk.com/dotnet/.net-framework/a-tdd-journey-1-trials-and-tribulations/). In part two, having recently introduced the three laws of TDD, he wrote the following (https://www.simple-talk.com/dotnet/.net-framework/a-tdd-journey-2--naming-tests-mocking-frameworks-dependency-injection/): [Test] public void Execute_delegates_to_IWidgetLoader_to_load_widget_details() { var activator = new WidgetActivator(); } At this point the test fails because WidgetActivator doesn't exist. He then proceeds to introduce a dependency and a constructor parameter before making the test pass: var mockWidgetLoader = new Mock<IWidgetLoader>(); var activator = new WidgetActivator(mockWidgetLoader.Object); When a commenter pointed out that he was violating the three laws of TDD of he commented: "When adding a new test, you do not stop as soon as it turns red; rather you stop when the test is completely written. Then you labor to make that test turn green by modfiying [sic] the class-under-test. Think about it this way: if you write a partial test then make it go green, you now have a passing test *that is wrong*. A test should be green if and only if it is valid." I disagree with the comment because it allows multiple unnecessary lines of code to be written and doesn't provide a progression that guarantees that all production code is effectively "tested"/covered. It also makes it harder to get feedback from the test about the design of the system. Sure, the developer might tweak the test code to improve the API but at that point the API design isn't supported by a working implementation so it's not necessarily going to reveal design defects as quickly. Another person pointed out that "an incomplete but green test is at best misleading and at worst wrong: if a test is green it should be a valid test, and a partial or incomplete test is not valid." --- An experience with coworker 2 --- Coworker 2 recently came to me with some questions. He described his process wherein he would: * Create an empty test * Add a variable assignment: var instance = new MyClass(); * Introduce the class * Add dependency1 to that class: var instance = new MyClass(dep1); * Add that dependency as a constructor parameter * Add dependency2 to that class: var instance = new MyClass(dep1, dep2); * Call the method to be under test: var result = instance.Execute(); * Define the method under test * Add a parameter to the callsite of the method under test: var result = instance.Execute(param1); * Add the new parameter to the implementation of the method under test * Add another parameter to the callsite of the method under test: var result = instance.Execute(p1, p2); * ... The story, in short, is that no matter what he was doing extremely small steps -- steps that felt unnaturally small to me. Ultimately he had a number of problems which seemed to be because he wasn't letting the tests guide the implementation but he felt the implementation went really slowly because after writing a fair amount of code and he'd have to come back and modify many of his tests when a new parameter to a method needed to be added. I introduced him to ATDD/double-loop TDD in hopes that it'd help him work in vertical slices, let the system evolve, and help him discover the required parameters/dependencies early in the process. --- Questions --- Both of the above experiences and questions go back to understanding the three laws of TDD and step size. As I'm entirely self taught, I'd like to know your thoughts. Do you strictly follow the three laws of TDD as literally written? What step size do you typically have when going back and forth between tests and code? How do you decide the appropriate step size? When writing a test, do you define a method or construct

Hi, Does anyone know of a good unit testing library for testing pdf in .NET? something similar to jPDFUnit? -- Lior Friedman Agile Consultant - AUT/TDD Expert | Mobile: 972.52.833.3660 | Email: lior@... Blog - http://imistaken.blogspot.com P.S. Follow me on Twitter & LinkedIn. See you there…

We've been using Ruby and Cucumber for ATDD/BDD, using PageObject and some other cool Ruby gems with Watir/Selenium drivers. We've found that approach preferable to using Cucumber-JVM or SpecFlow, even though the apps we're testing aren't being written in Ruby or Rails. Some of my colleagues would like to automate testing of the American's for Disability Act 509 compliance, others of us think 509 compliance is something better done manually. In any case, does anyone on this forum know of a good Ruby gem for 509 compliance? If not, do you know of any other good approaches to automate testing of 509 compliance (open to non- Ruby options, if there isn't a good Ruby alternative). thanks, Camille

People have told you about tools, as far as practices go I would recommend Ian Cooper's video TDD Where Did It All Go Wrong, it explains how the original ideas around testing units of behaviour (as in Kent Beck TDD by example) got a bit distorted and then explains how it should work

TDD, or at least the ideas behind it, is a lot older than that. NUnit and SpecFlow are both pretty awesome. There are also a number of good mock tools: NSubstitute, Rhino, Moq, etc. You should play with a few to find a style that suits you.

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years. I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

Hello folks, I created a simple opensource tool for testing user interfaces called FunTester (http://funtester.org), and I would like to hear your thoughts about it. It is a model-based testing tool, and generates and executes functional tests from use case specifications. The tool is still under development and doesn't have all the features (and documentation) I wish it had. The interesting about it is that it generates tests with data and oracles, combine different use cases, use techniques such as Equivalence Partitioning and Boundary-Value Analysis, and can use test data from external sources, such as relational databases. The current version generates tests for Java Swing user interfaces with TestNG and FEST. We just started creating another plug-in for Selenium + JUnit/TestNG. Plug-ins can be created for (generating code into) any programming language and unit/GUI testing frameworks (i.e. Python, Ruby, PHP, C#, ...). As the tests can be generated *before* the software is implemented, the software can be implemented to pass the functional tests. Glad to hear your thoughts, - Thiago Delgado Pinto

Ever? Is that even possible? There must be some part of the code that "remembers" what it has previously generated and checks whether the string just generated is among them. So, shouldn't this part of the code be put into a separate function with its own unit tests. This function must have the candidate string as a parameter and the history as the class or parameter, so you can TDD this logic with whatever inputs your unit tests needs, right? That tests whether the function does what it is supposed to. You would also have to TDD that the history structure is being correctly built. If you then want to also test whether all the code works together, if you can inject the length of the strings and the character set they are generated from, then you can be sure that for a very small length and character set, duplicates will get generated quickly enough to validate that it really works. More interesting is how you could test whether the strings generated are sufficiently "random".

I don't know anything about iOS programming, so what I say might be completely useless to you. Anyway I will try a suggestion: Can you imagine to test drive not the view themselves, but the code that builds the view? If this was a web application, I may want to write something like the view builder: ... view.addHeading("foo"); view.addParagraph("bar"); ... the view object contains methods that make calls to the display technology. In html that would be just void addHeading(String content) { this.html += "" + content + ""; } in iOS you would have calls to the iOS APIs in there. The view builders would know nothing of iOS and could be easily test-driven. Once you have a void addGrayedOutButton(String title) method working, and you know that it works because you've seen it working once, you shouldn't need much more testing unless you change its body. Matteo