[...] > > Indeed. In fact, there's really three facets: code, > > tests, and specs. All three are needed. > > > > This is part of why things like CASE/MDA are doomed to > > failure as they try to smear all three together. The > > whole point is that each of the three provides checks and > > balances against the other two parts of the trio. > > I wonder, though. There are many teams which merge > specification and test and end up doing very well. The > "double check seems" to do okay, so the "triple check" > seems to need justification.
No, they still have the three facets -- it's just that the specs only get manifested in both the tests and the code. The people still have to say: "yes, that does what I meant."
[...] > > Hmm... You seem to be presuming that those languages allow > > for a multiplicity of forms to say the same thing. Why? > > I think they all do.. I can say 1 + 3, or 2 + 2, and > that's just a base case. I think every language provides > an infinite number of ways of writing most programs.
You're stuck thinking about general purpose programming languages. Think: domain specific languages.
> > Doesn't the adage "Do one thing and do it well" apply to > > (domain specific) language design? > > Yeah, but that's at the language level. Sort of, if a > language allows a + 1 and a++, it isn't as simple as it > could be.
Indeed but often the languages add seemingly redundant constructs because they connote different things (even though there is overlap). That's one of the problems with general purpose programming languages vs. specific purpose programming languages.
> I think that if there is a way of mutating among most of > the many forms that the same computation can be expressed > in, in a language, we'd have an incredible tool. You > could take the nastiest code, dust it off, and resurrect > it, knowing that it does exactly what it did before. I > don't know how much of this is computationally feasible, > though. I suspect there are some points 'a' and 'b' that > you simply can not refactor across and know you've done it > right via code analysis.
In general, that's got to run into the halting problem. In specific, there's tons of stuff that such a tool could do.
The big question to me is: why? It sounds like you're asking for a tool to help you deal with the complexity of the general purpose language that you're trying to use to implement the many specific purpose languages that you're building to build your systems. I'm suggesting that you sidestep that and go directly to the issue of consciously and conscientiously creating the specific purpose languages that you actually need to directly create your system.
> > However I believe that if TDD is > > not used in conjunction with CT then it becomes > virtually > > useless. > > Hogwash. TDD induces a lot of improvements over the > status quo development methodologies including > highly-iterativeness, use-driven design, granularity > reduction, etc. along with getting a lot of developers to > open up to the notion that tests have a direct, positive > benefit to them.
Maybe what I stated is incorrect, and there is some value in TDD without CT, but CT is much more important than TDD AFAIC. (yay acronyms!)
For what it's worth, I think we'd be better, as an industry, if we concentrated more on change verification than program verification...
Yes. The important thing to understand about unit tests is that they facilitate refactoring. That means their real value is that they help you write malleable code, in more ways than one. Since we rarely (probably less than half they time, eh?) crank out a version 1.0 that's perfect and remains unchanged thenceforth, that is a valuable thing.
Sadly, the word "test" in there seems to lead many people to believe that they do some kind of magical system testing. Just throw in a couple unit tests and, by golly, you can fire the whole QA group!
Not relating to any response but on the same topic, are tools such as JUnit really necessary?
Surely one can take the 2 or so minutes per method written to implement a corresponding method that ensures that his/her method returns the correct String or the correct boolean value etc.
I'm really not for these second-party testing software tools such as JUnit, etc. (In any case they too are just bulked up software that could be buggy - how did the authors test that their little modules function well? They wrote customized testers for their methods and units, and so the cycle goes on. Isn't it enough to just stick in snippets of code to ensure proper return values? Would this also be considered as TDD? BTW, JUnit sucks!! - :o) I'm just kidding.
For what it's worth, I think we'd be better, as an industry, if we concentrated more on change verification than program verification... We know how to say that - regression testing.
> For what it's worth, I think we'd be better, as an > industry, if we concentrated more on change verification > than program verification...
> We know how to say that - regression testing.
Yes and no. Regression testing only helps protect from screwing up existing code from expected issues (i.e., those that we already have thought of (at least enough to cover them with a test, even if unintentionally :-)). Regression testing does nothing directly in terms of helping us making forward/additive "changes". Regression tests also (nominally) increase the amount of work when making changes that are mutations of the existing features (because we have to go back and change (many) tests as well as the code).
To be clear, I'm all for automated regression tests. It's just not the be-all and end-all of testing.
> > Isn't it enough to just stick in > > snippets of code to ensure proper return values?
No.
> You mean like contracts?
:-) Indeed.
However DbC and TDD are complimentary rather than some sort of competition even though there's obviously a lot of overlap between those approaches.
However, from the ensuring correctness point of view, the contracts approach helps induce a more rigorous approach because the intent isn't just to make the tests pass but to precisely and exactly define the correct behavior.
> > For what it's worth, I think we'd be better, as an > > industry, if we concentrated more on change > > verification than program verification... > > > We know how to say that - regression testing.
> Yes and no.
Apologies for not checking what Michael Feathers was refering to - incidentally, the company name has changed to 'dynamic aspects'.
> Regression testing only helps protect from > screwing up existing code from expected issues (i.e., > those that we already have thought of (at least enough to > cover them with a test, even if unintentionally :-)). > Regression testing does nothing directly in terms of > f helping us making forward/additive "changes". > Regression tests also (nominally) increase the amount of > f work when making changes that are mutations of the > existing features (because we have to go back and change > (many) tests as well as the code). > > To be clear, I'm all for automated regression tests. It's > just not the be-all and end-all of testing.
The approach Michael Feathers was pointing to doesn't seem to be about 'testing' at all.
I'm really not for these second-party testing software tools such as JUnit, etc. (In any case they too are just bulked up software that could be buggy - how did the authors test that their little modules function well?
Do you realize how simple it is to create your own JUnit tool?
Flat View: This topic has 26 replies
on 2 pages
[
«
|
12
]
Previous Topic
