xtreme programming, ага - 2

[109]

PS. читаю сейчас http://xprogramming.com/xpmag/expUnitTestsat100.htm и не знаю, плакать, или смеяться:

"Suppose it only took a tenth of a second to compile, link, and test your entire system. OK, I admit I'm extreme, but even I know we can't do that. But go with me here -- let's imagine what would happen if we could. And while we're at it, let's imagine that our tests are comprehensive: they test everything that needs to work. When our tests run, we're sure the system is right."

(обратите внимание на "let's imagine")

"The really wise [XP] teams write a test first, then a little code, then another test, and so on. Teams are reporting 100% coverage using this technique alone, which is quite good in a lot of environments."

(теперь, значица, "let's imagine" уже нет - типа 100% coverage у XP teams сам получается, стоит лишь назваться XP team)

"Your team could gain these advantages too. Just write automated unit tests and keep them at 100%. We're sure that if you do, you'll see improvement right away."

(и при этом ну совершенно не говорится, как же добиться этих 100% coverage, уж не говоря о том, сколько это будет стоить и занимать времени. "tenth of a second", ага!)

Comments

[auto194419.livejournal.com]

è åù¸ (http://www.google.com/search?q=cache%3AAasUWyo5G6U%3Awin-www.uia.ac.be/u/sdemey/Teaching/SSPEC2LIC/Archive/FormalSpec-avl.pdf+paris+metro+ada+validation+project+translation&hl=en):

A recent, fairly impressive example is worth pointing out
[Beh99]. The Paris metro system has recently opened a new
line (line 14, Tolbiac-Madeleine). The traffic on this line is
entirely controlled by software. Driverless trains and conven-
tional trains are both supported. The safety-critical compo-
nents of the software (located on board, along the track, and
on ground) were formally developed by Matra Transport
using the B abstract machine method [Abr96]. The develop-
ment includes abstract models of those components, refine-
ments to concrete models, and automated translation to ADA
code. According to [Beh99], there are about 100,000 lines of
B specification, covering the abstract and the concrete
model, and 87,000 lines of ADA code. The refinement was
entirely validated by formal proofs. The B tool automatically
proved 28,000 lemmas and 65% of the rules added to dis-
charge proofs. Many errors were found thereby, and fixed in
the concurrent development. In addition, a conventional test-
ing process was deployed and not a single error was found.
The success of this formal development might be explained
by the unusual combination of success factors. The B speci-
fication language has a simple mathematical basis that
allows engineers to use it after a reasonably short period of
training; the specification technique is multi-level and makes
it possible to smoothly move from an abstract model up to
code in a provably correct way; methodological support was
provided in the form of guidelines and heuristics to guide the
development and validation processes; a development/vali-
dation process model was first designed explicitly and inte-
grated in the company's process model to accommodate
conventional practices such as testing (the lack of such inte-
gration has been recognized to be a serious obstacle to the
adoption of formal methods [Cra95]); last but not least, the
process was supported by powerful tools.