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 <gakouse...@hotmail.com> 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
------------------------------------------------------------------------------
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
