Ubuntu Announces Mir, A X.Org/Wayland Replacement

[timothyja]

TDD.

who hasnt developed a test driven project may easily dismiss the implication of this detail, but having worked with it for some games i can say it's quite deep actually...

you have to write unit tests to see them initially fail (of course, classes and code dont even exist yet), then the (minimal) code that will make them pass (green bar in the test runner - all test methods satisfied), then refactor the code (and the tests, if you change the class hierarchy or method names) to refine the design

this leads to (ideally) have smaller iterations, and working (and pre verified) code at each iteration
but this also implies a NECESSITY to have the whole project developed in TDD, so that each project subunit is covered by tests, so that bugs or regressions introduced with subsequent feature iterations or refactorings, are immediately caught
otherwise there's no point in going TDD at all

this means that, canonical may be "right" or "wrong" by choosing such development strategy, but that doesnt matter - since they have choosen it they can't import foreign, non tdd code any more
so no, they couldnt "just fork" an existing solution ... even if it may work just fine, even if it may be the most popular, even if it's in development for some years and even if its developers are brilliant people, the fact that they havent worked with programmatic description of specification and the fact it comes without unit tests make it a no go
this is important to understand

Rubbish you can do TDD on an existing project. Yes its takes a long time to get coverage but it just involves adding tests for any new code.

[Alex Sarmiento]

Canonical Marketing is doing a great job. Positive words for shitty ideas. First Harmony and Unity, now Mir(peace). Nice work marketing. Now lets drink to five years of further fragmentation and building walled gardens.

How are those shitty ideas?

[Alex Sarmiento]

Either way, they're done with Linux, IMHO.

Nobody's ever forked their other projects before, I don't see this being any different.

Do you have any idea how many ubuntu fork distros are out there????!!!! Gosh!

[silix]

you can do TDD on an existing project.

it wouldnt be test driven development, but test retrofitted at best..

retrofitted tests (being usually written against the nominal use case's specification) help spot anomalies in the observable effects of the running application
but unlike tdd testcases written before code (possibily more than one for each line of code, for the correct as well as the undesired behaviour), they are not in direct correspondence with the code they test
thus they dont guarantee that the code is minimal (only the one "necessary and sufficient" to make the test pass ie satisfy specifications - minimality which in turn typically makes the code cleaner and more readable) nor that you cannot "change a LoC without at least one test faling" (which is the imperative with pure tdd)
thus dont guarantee against possible hidden bugs
and, they dont account for code documentation - unlike tdd testcases which should possibly suffice to understand the program's internals (since they're a programmatic embodiment of the program's specifications)

Yes its takes a long time to get coverage but it just involves adding tests for any new code.

so you spend a long time (possibly longer than with tdd - since to get a working prototype you rush development ) adding stuff that wont, by itself, make the rest of the code more streamlined, more readable, directly documented or directly mapped over working specs - which you'd possibly get directly using TDD... i fail to see the point of it...

of course, TDD like other forms of Agile development isnt perfect, far from it - but if anything it gets you code at every iteration ("early release") that you can assume to work (ie code you dont necessarily have to go back to for bugfix testing etc, later) as soon as the iteration is complete (all test passing, assuming tests are correctly written themselves), and is inherently documented and minimal, since the earliest iterations

OTOH, to get this you have TDD should be used from the start , hence canonical's decision

[timothyja]

it wouldnt be test driven development, but test retrofitted at best..

I know what TDD is and no I'm not talking about retrofitting tests. I'm talking about any new lines or code having tests written first. Sure this misses some of the advantages on starting with TDD (such as making sure you are only have code that is 100% needed) but its still TDD and eventually over time you will have enough tests that you will gain the full advantages.

so you spend a long time (possibly longer than with tdd - since to get a working prototype you rush development ) adding stuff that wont, by itself, make the rest of the code more streamlined, more readable, directly documented or directly mapped over working specs - which you'd possibly get directly using TDD... i fail to see the point of it...

Sure I 100% agree with you if you are *starting* a new project TDD makes a lot of sense. But (and I should have made this point in my last post) TDD is not a reason in itself to start a project from scratch when you have an existing project that has reached a stable state and you are not going to be doing anything a whole lot different.

In the case of Mir if TDD is so important than why not push for it to be used by the Wayland project rather than reinventing a stable project.