What I have seen from TDD is the following:
- Lazy behavior - developer types (or the 'testing group') run off to
write a lot of 'test code' instead of asking the hard questions of
stakeholders - pushing on things that are not solid, etc (TDD generally
has it's own 'syntax' like an additional programming language).
- Since it is it's own syntax, you are essentially writing additional
code. Not nearly as much code as the actual "function" - but it is
separate and distinct. This means if that "difficult" requirement
finally gets resolved and things are different than expected (because of
the upfront lazy thinking), you have to go back and change both the
"functional" and "test" code that was incorrect.
- After about a lot test cases are created, maybe 1,000 (many of them
performing things like 1+1=2, right?) the team expectations start to get
damaged. E.g. a new Story (requirement/function) is completed and run
through the test definitions. 999 tests passed, 1 test failed. Most
'non-developers' on the team think things are still going great - but it
just so happens that 1 thing that failed was solely related to the one
new thing released. It's a critical function, the software cannot
proceed without it. But... but... 99.9% of everything is working right?
- Due to the encouraged lazy thinking and the 'number of tests' dilution
of understanding, the actual 'test programming' becomes worse over time
(on big projects). And if some nutcase happens to throw "Sarbanes Oxley"
at the project (separation of roles), then you have people writing test
code devoid of understanding of the developers approach. That sounds
good on the surface, but in my experience such failures were not caused
by the 'business need'. After the failure, the tester and developer
talk, and usually the tester changes their code to make the test case
work (the developer had a better handle on the requirement). That's time
spent on making TDD work, not implementing business requirements.
- If there is a separate testing group, TDD encourages 'magic
requirement creation' - a requirement appeared out of thin air, not
requested by the stakeholders/project owner. That is scope creep, plain
and simple. The sad thing is instead of bubbling such things up to get a
ruling, inexperienced developers often just go off and burn more time,
writing more code to meet the 'magic requirement.' Note that this issue
isn't a direct failing of TDD, but if there is an independent testing
group in charge of the TDD, then it empowers them, I'd say encourages
them, to bleed the project this way.
- In summary, with TDD, a lot more time is spent accomplishing the end
result.
Clearly I'm focusing on the negative to give some balance. TDD does make
you 'think' about things. But really, you should have been 'thinking'
about those things already.
As an allegory I'll bring in the concept of Agile development. What I
have found is the main benefit of Agile is not the SCRUM, Kanban,
just-in-time-requirements, ability to change priority mid-stream, etc.
The benefit of Agile is building an actual 'team' that includes
EVERYONE, testers, stakeholders, developers... everyone. As the project
goes along it becomes easier and easier to identify those that are not
really part of the team. You eject those people or make sure everyone
knows the project is at risk because they are there (after the
appropriate coaching, pleading, etc, to try to get them to change their
behavior).
So, Agile gives a way to get to what should have already existed - you
just get there sideways instead of straight-away.
Likewise, TDD helps get done what should have been done anyway - but
kinda sideways.
For me, I write software 'defensively' by nature - decades of coding and
the need to maintain it for those decades drove me there. So my forays
into TDD have only led to increased time with no significant benefit in
results.
But across the spectrum of software languages, businesses, so-called
standards, best(worst) practices, individual agendas, personal 'skill
level', office politics, muddled technologies, and outright lies in our
industry, you do what you can to accomplish your goals. So by all means,
use TDD if you enjoy it or think it forces discipline in a weak area.
But it is most certainly not a silver bullet that kills all the
baddie-werewolves we face in our industry.
-Charlie
On 7/23/2020 1:17 PM, Garrett Fitzgerald wrote:
I still have trouble conceptualizing how to write unit tests for data
access.
On Thu, Jul 23, 2020, 11:37 MB Software Solutions, LLC <
mbsoftwaresoluti...@mbsoftwaresolutions.com> wrote:
I have done it that way before, and it works well. I wrote the DataObj
and BizObj first before the UI for those purposes. But alas, those are
...
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message:
https://leafe.com/archives/byMID/b8c17aeb-14d6-6e4a-a1c4-a6a71ae67...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
