[Factor-talk] Test Driven Development
Hi, Test driven development completely baffles me. Any advice on this topic and how to make effective use of Factor's tools? -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Test Driven Development
uhhm, i might not be *the* right person to answer this but: test driven development (TDD) is a pretty open field in pretty much anything. it mostly boils down to testing that when you give a function some input you get the proper output. methodology wise there's pretty much no certain paradigm to follow, or rather they range from writing full coverage tests before actual code and testing whole ranges of types vs not writing any tests at all. what i just thought up as a neat methodology would be not writing tests at all unless you encounter a bug and then try to locate the bug through testing and fix it. for clearer advice you might want to state your question more specifically. On Sun, May 26, 2013 at 2:14 PM, graham telfer wrote: > Hi, > > Test driven development completely baffles me. Any advice on this topic > and how to make effective use of Factor's tools? > > > > -- > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Test Driven Development
I agree with Alexander, that this is a term that has come to represent a number of different things to different people. One core idea is that you attempt to capture in some set of assertions what the correct expected outcome is of a particular unit of code, given a particular set of test inputs. The test inputs and expected outputs become a kind of spec for the code unit that defines the view of it from the outside, and leaves internal implementation details completely unspecified. This enables you to change the internal implementation of that code unit in any way you wish, so long as your changes continue to produce the expected outputs and continue to pass your test assertions. This approach can be used in a number of ways: * you can refactor your code to give it a more a better structure and more desirable qualities, as long it continues to conform to the test specification * you can substitute one or more pieces of the implementation with something more useful for a particular task at hand (for example, a fake database access component that hard-codes a particular database query result and returns it to the caller without actually having to be connected to a database at all, thereby executing more quickly and in a more isolated environment, yet still producing the results needed by the code under test) * in a similar fashion you can substitute implementation components with ones that add some sort of useful instrumentation to the real components * more generally, if you structure your code relationships and dependencies in such a way that you pass in (or "inject") into the "depender" a separate unit of code that fulfills a dependency, then you can substitute that dependency-fulfilling code with any of a number of substitutes that accomplish some of the goals mentioned above. This technique is sometimes known as "inversion of control", where a piece of code turns to something from the outside to tell it what it is depending on, instead of building that control information into the code itself. * etc., etc., lots of useful techniques have been built upon these concepts The idea is to make tests that provide inputs to the code under test and that test test expected outcomes as lightweight and fast as possible so that they can be run without cost on a regular basis. Then as you modify tested code or other code that might have side effects affecting the tested code, you can automate the execution of your tests and have them tell you when you have broken something that used to function correctly. Some folks write the tests first before they even write the code being tested, leveraging this idea of a test as a spec using that spec to guide the development of their code. Others code first and write tests afterwards, as a longer-term guarantee that whatever subsequent changes are made to the code (or other code that can affect it) those changes have not in any way invalidated the correct functioning of the code that the test covers.People talk about percentage of code coverage as a gross measure of how strongly your code is protected by such guarantees. It is not always practical or possible given other constraints to take the time to achieve 100% code coverage (and there are likely portions of your code that won't benefit from tests as much as others and for which it is probably a waste of effort to do so). Date: Sun, 26 May 2013 14:34:56 +0200 From: ddo...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Test Driven Development uhhm, i might not be *the* right person to answer this but: test driven development (TDD) is a pretty open field in pretty much anything. it mostly boils down to testing that when you give a function some input you get the proper output. methodology wise there's pretty much no certain paradigm to follow, or rather they range from writing full coverage tests before actual code and testing whole ranges of types vs not writing any tests at all. what i just thought up as a neat methodology would be not writing tests at all unless you encounter a bug and then try to locate the bug through testing and fix it. for clearer advice you might want to state your question more specifically. On Sun, May 26, 2013 at 2:14 PM, graham telfer wrote: Hi, Test driven development completely baffles me. Any advice on this topic and how to make effective use of Factor's tools? -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Re: [Factor-talk] Test Driven Development
Michael Clagett wrote: > I agree with Alexander, that this is a term that has come to represent a > number of different things to different people. I don't think that's a good answer. Yes, some people have used Test Driven Development to refer to their own personal process that happens to use tests; but TDD was originally developed as a component of Extreme Programming, and as such there is a clear definition. TDD is the subset of XP that can be practiced by a solo programmer. Before I discuss this, there's an important question: are there any test frameworks for J? > Some folks write the tests first before they even write the code being > tested, leveraging this idea of a test as a spec using that spec to guide > the development of their code. That's part of TDD -- without test-first, the development isn't driven by the tests, and there's no point in using the name. The most essential part of TDD is that you should NOT write a single line of code that isn't required in order to make a _failing_ test pass. So in order to add a new feature, you start by writing a test that you expect to fail -- but you expect to be able to make pass easily. Run the test and make sure it fails! Don't skip that step -- better programmers than you have been fooled by their own code. Then write just enough code to make it pass, and rerun your tests to confirm that they do pass. Repeat as needed. That's the essential skeleton of TDD. There's some judgement involved, and guidance to help you decide where to start; there are also automated test runners to help you run your test suite more frequently (as yours tests get bigger it gets harder to run them with EVERY little change). Those put meat on the bones. -Wm -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Test Driven Development
Yes, it's true that the term TDD originated with Kent Beck and the Extreme Programming crowd and that the narrower, more precise meaning that you are favoring is what was intended by these folks. But test-first is not the only mechanism available to making testing central to development, and it is this centrality that I take to be what Test-Driven is all about. So in this broader meaning, which granted is not necessarily what the XP folks had in mind, the ability to and the intention to test drives the entire design and development process. It is a natural extension of at least part of what the XP folks were promoting, but with a nod to some of the constraining realities of a typical modern development environment, where a test-first mentality is often not shared by all the participants who would need to embrace it for it to be practiced effectively by a wider development group. Use of design techniques such as dependency inversion, single responsibility, and the other SOLID principles all help build code that is extremely testable whether you happen to do it before or after coding and a testing mindset drives the entire development process. So take your pick whether you wish to embrace a narrower or wider meaning of the term. But they do both exist. Sent from my iPad On May 26, 2013, at 11:31 AM, "William Tanksley, Jr" wrote: > Michael Clagett wrote: >> I agree with Alexander, that this is a term that has come to represent a >> number of different things to different people. > > I don't think that's a good answer. Yes, some people have used Test > Driven Development to refer to their own personal process that happens > to use tests; but TDD was originally developed as a component of > Extreme Programming, and as such there is a clear definition. TDD is > the subset of XP that can be practiced by a solo programmer. > > Before I discuss this, there's an important question: are there any > test frameworks for J? > >> Some folks write the tests first before they even write the code being >> tested, leveraging this idea of a test as a spec using that spec to guide >> the development of their code. > > That's part of TDD -- without test-first, the development isn't driven > by the tests, and there's no point in using the name. The most > essential part of TDD is that you should NOT write a single line of > code that isn't required in order to make a _failing_ test pass. So in > order to add a new feature, you start by writing a test that you > expect to fail -- but you expect to be able to make pass easily. Run > the test and make sure it fails! Don't skip that step -- better > programmers than you have been fooled by their own code. Then write > just enough code to make it pass, and rerun your tests to confirm that > they do pass. Repeat as needed. > > That's the essential skeleton of TDD. There's some judgement involved, > and guidance to help you decide where to start; there are also > automated test runners to help you run your test suite more frequently > (as yours tests get bigger it gets harder to run them with EVERY > little change). Those put meat on the bones. > > -Wm > > -- > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Test Driven Development
Michael Clagett wrote: > So in this broader meaning, That's fine, but he didn't ask about a broader meaning. He asked about TDD by name. More aptly, he asked about TDD tools people use with J. Are there any decent test frameworks with J? I haven't built any projects big enough that I wanted a testing framework, but I join him in wanting to know if any exist. Once someone's built a framework, it's usually possible to jury-rig that into one of the continuous integration tools, so long as the framework isn't TOTALLY specific (like using graphics instead of text). > It is a natural extension of at least part of what the XP folks were > promoting, It's possible -- given this statement -- that you either have a natural talent as a tester, or that you've never used TDD. If that's true, you either don't know how hard it is for most programmers to test their code or you don't know how easy it becomes to do so when doing TDD; and either way you don't know how different TDD is from "programming using tests". "Test driven design" is not simply a narrow specimen of "testing in general". TDD is an extremely clever design that solves serious problems that programmers experience with testing in general. > but with a nod to some of the constraining realities of a typical modern > development environment, where a test-first mentality is often not shared by > all the participants who would need to embrace it for it to be practiced > effectively by a wider development group. As I've mentioned, TDD happens to be the smallest core of Extreme Programming that can be implemented without team support (or while working alone). > Use of design techniques such as dependency inversion, single responsibility, > and the other SOLID principles all help build code that is extremely testable > whether you happen to do it before or after coding and a testing mindset > drives the entire development process. So take your pick whether you wish to > embrace a narrower or wider meaning of the term. But they do both exist. All true! But none answer the poster's question in any sense. Would you tell me how to program with J by pointing out the fact that few keyboards ship without a "J" key? (Is that too sarcastic? I hope not -- I hope you find it more amusing than offensive. If not, I accept blame; but hopefully it is funny.) -Wm -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
