1

I'm approaching the TDD methodology for software development, reading guides and writing simple applications, because a client of my company wants a software and asked to develop it using TDD methodology.

So I was wondering, besides "trusting" the documentation and reports we'll create, how can one understand and be sure that TDD was followed. I thought that maybe the content of test can be different from the one that would be there if written after coding, but I'm not completely sure.

And even if this was the case, what are the hints I should be searching to understand if the software was developed that way, if I were to look to someone else's project?

|improve this question
  • 2
    Just like with any other methodology, trusting documentation is the only way. And as an offtopic I would like to add, that I find it absolutely ridiculous that a customer tells you how you should develop the software. – Aleksander Mar 21 '19 at 17:09
  • @Aleksander well I'm just a poor junior developer, I have to follow the orders – TodorokiM Mar 22 '19 at 8:11
1

Objectively, there is no way to find out if the tests were written test-first or test-after.

But my personal opinion is that someone who is truly experienced with TDD will recognize if code was written test-first or test after. As they produce noticeably different structures and code. Also I have found that writing test-after often causes major edge-cases to not have tests. Even whole areas of code might not be covered by tests as there was stress to continue writing "production" code instead of tests.

|improve this answer
  • 1
    Well, TDD doesn't guarantee 100% of coverage either. But agreed with writing test-after often causes major edge-cases to not have tests. – Laiv Mar 22 '19 at 7:40
  • 1
    @Laiv Strict TDD does result in 100% code coverage by definition. As one of the rules of TTD is "Never write production code without test for that code". But strict TDD is quite difficult and often not economical. – Euphoric Mar 22 '19 at 8:55
  • @Euphoric It's the same thing with all methodologies. You can't really follow their textbook definitions and if you can, then in most cases it is still not the best thing to do. So I'd say it is not very reasonable to demand a software developed using certain methodology to follow said methodology word by word since normally only strictly regulated industries do that. I.e. car manufacturers have to follow strict V-Model to conform the ISO 26262 etc. – Aleksander Mar 22 '19 at 13:56
6

You can't prove that a particular methodology was applied to arrive at a particular result.

However, in the specific case of work-for-hire, where the customer owns the resulting IP rights, they could ask for the whole history of development as recorded by your source control tool.

If that history shows that you add a test, then add implementation, then refactor, as separate commits, then it's pretty indicative of TDD being followed. It still isn't proof, as you could construct such a history post-hoc, having developed under some other methodology, but I can't imagine such a ruse being cheap.

|improve this answer
  • 1
    This exactly what I was asked to do once to prove I used TDD for the -challenge- test. Note that, It can be faked as Caleth says. It just takes to implement the solution on one side and then re-do it on another side following TDD so that the SCM history shows exactly what the stakeholders want to see. – Laiv Mar 22 '19 at 7:36
1

I suppose that using TDD will result in a cleaner code and design. While clean design doesn't automatically mean that TDD was used.

I'd analyze such things when assuming TDD was used:

  1. A class has more getter functions than is used: to call them from tests to check a state.
  2. There's a small amount of High cohesion: such things are difficult to test.
  3. Each class has a unique responsibility.
|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.