Jenk is leaking BDDB/TDD
I wouldn't suggest dropping Code Review - but it's progressively of less value as the experience of the developer goes up. I think Kieran (finallyEverah wrote:Ok, I am lost a little bit then. Don't we all want high efficiency, bullet proof code that not only works, but works well and securely? If the only review of the code is not even a code review but a test result review, how does that ensure the state of your code? Or am I looking at this the wrong way?
At the same time - reviewing test cases or behavioural specs is really important. What's the point of pretty code with really ugly tests which cover nothing? This is even more important where B/TDD is not applied - test writing after the fact is quite a bit more difficult and it's easy to cop out and take the easy route of testing only what you can, and doing some quick or badly designed integration testing for the rest.
Depends on what you want to do with TDD - design or test? I had this argument with arborint beforeCoderGoblin wrote:I have looked at TDD and realise its usefulness but still cannot get my head around it (especially mocking database requirements which seem to make up the bulk of things I do). When I started coding I seem to remember being taught that 80% of code is input/output with 20% actual processing. TDD is great for that 20% but I remain unconvinced of it's place for the rest.
An example I could use is a financial accounts system. Designing it might be very easy applying TDD or BDD, but afterwards you are not going to leave it at that. I would personally write the report damning you to hell