Can I verify test driven development?
can test driven development formally verified? Is there any guarantee that the program is correct and work properly? Is there any formal bases for choosing test? is there any algorithm to follow it?
TDD is no silver bullet. You still have to write the code and you can still make mistakes in your logic and in your code. I see TDD as a thinking tool that helps you work through a problem in a very systematic way. Here are some articles that may help you in terms of what algorithm to follow: The 3 rules of TDD The Transformation Priority Premise
It's a good point that, without a formal specification of what the system does, it is difficult to write a set of tests which are known to be adequate. Here are a few papers which might help, along with quotes from their abstracts: http://www.pst.ifi.lmu.de/~baumeist/publications/baumeister04a.pdf "The goal of this paper is to show that it is possible, with appropriate tool support, to combine formal specifications with test driven development without loosing the agility of test driven development." http://wiki.overturetool.org/images/d/df/WS9Mochio.pdf "This paper presents the use of VDM++ formal specification language as a basis of scalable agile formal (SAF) software development method, which is an agile method for mission-critical or large-scale software development" https://online.tugraz.at/tug_online/voe_main2.getVollText?pDocumentNr=275810&pCurrPk=67400 "In this paper we propose the combination of several techniques into an agile formal development process: model-based testing, formal models, refinement of models, model checking, and test-driven development."
TDD is an empirical, example-based process, not a proof-based approach. In terms of correctness, it's only worth as much as the practicioner's rigor allows. TDD provides guidance as to how to program driven by tests, not what to program or test -- you could pretty much TDD to the perfection an implementation that does nothing, or passes clueless tests. You can however apply traditional testing techniques like Equivalence Partitioning to increase the completeness of your TDD tests. Code coverage analysis also provides an (incomplete) view on the validity of your tests. For a more theorem-proving oriented approach, you can check out Property-based Testing. It can be attacked with a TDD mindset, although the TDD cycle will certainly not look like a canonical one in such a context.
can test driven development formally verified? There is no formal verification of test-driven development since the main objective of it is not to produce tests but to provide a way to approach design and coding. Is there any guarantee that the program is correct and work properly? I don't think that there is a full guarantee that the program is correct no matter which approach we take. Is there any formal bases for choosing test? The way we're choosing tests in TDD is by writing those that should guide us through the implementation of the next unit of code we're about to write. is there any algorithm to follow it? It's actually very simple (but hard to get proficient with). Think about the next unit of code that should be written. Write a test that will fail since there is no implementation code. Write the code and confirm that the test is successful. Refactor
junit - share a fixture between testcase
How to use TDD correctly to implement a numerical method?
What is Best for Defect Rate Tracking? Defects per KLOC?
TDD with IronPython [closed]
Gallio Icarus vs. Testdriven.net [closed]
Can we come up with a better name for TDD?
TDD in an large project: How do you get started?
How do I get sufficient detail in planning and estimation when using TDD?
What design models to create before TDD?
BDD/TDD: can dependencies be a behavior?
What is the best description of TDD? [closed]
TDD and development time
When stop testing using TDD?
Is it normal to have a long list of arguments in the constructor of a Presenter class?
When to Expect and When to Stub?
How do I test Prism event aggregator subscriptions, on the UIThread?