Where's the Unit Testing?

Question

Where's the Unit Testing?

Viewing 3 posts - 31 through 32 (of 32 total)

You must be logged in to reply to this topic. Login to reply

Eric M Russell SSC Guru Points: 125562 More actions · Answer 1

David.Poole (7/26/2016)
I get the point about 10x data loads but that is stress testing rather than unit testing.
Stress testing is incredibly important. The reason for separating out unit, integration, NFR testing etc is down to the speed at which the tests can be run.
The point of unit testing is that you are testing a wide range of functions at high speed. If you don't pass this stage then you'll never get to the integration stage. Unit testing gives fast feedback to the developer. If they have to sit around for 5 minutes or longer waiting for a build to compile and run all the tests then pretty soon they'll start reducing the scope of the tests.

For me, stress testing is part of unit testing, if it's done at the unit level. If I write my SQL against a large table, then I know from day 1 that what I'm doing will scale for large tables. I don't want to release a deliverable to QA and then discover it doesn't scale, because that involves refactoring.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Kim Crosser SSCommitted Points: 1763 More actions · Answer 2

TomThomson (7/26/2016)
Actually, the fundamental design problem in that case is that the developer hasn't a clue how to go about software development. If he started doing design with testability, error management, security, and how his bit has to interact with the rest of the system in mind and thinking about how to break down his bit into sensible self-contained subunits he wouldn't have much trouble designing unit tests, dummy interfaces and placeholders (I think those are now called "mocks"? but I stick to the terminology I know) and organising his placeholders so that they can be told to pass erroneous junk to teh code under test so that he can see his error detection (and maybe the rest of his error management) working (or discover that it's not working), and he wouldn't have a horrible over-complex heap without internal functional division to break in a mysterious and incomprehensible manner as soon as it hits the machine.
But then a lot of modern developers usually haven't heard of error management, their training has been about how to throw together spaghetti in C++ with no attention to engineering principles or to computer science.

Precisely the point of my previous post (with McConnell's quote on more weighing not helping you lose weight). You can throw a lot of resources into increased testing, but if the underlying code is poorly designed and structured, you just wind up with more and more spaghetti code as the developers apply more patches to try to fix bugs found in testing.

Now there is a national initiative to teach every kid to code, but where is the national initiative to teach software engineering and architecture? :w00t:

On the positive side, I see a huge employment opportunity for those of us who can come in and fix the messes created by these "script kiddies". 😉

Andrew..Peterson SSCertifiable Points: 6838 More actions · Answer 3

Gary Varga (7/26/2016)
Andrew..Peterson (7/25/2016)
From my observations, this is a management issue. And as you stated:
"...perhaps a few bugs aren't a problem. Maybe the impact is low enough that training developers to write tests and making the investment isn't valuable enough."
Like continuous integration, devops, etc. a few want a solid product, the many will wait to fix the bugs after the fact. I guess it makes it easy to prioritize which bugs to fix?
I am not convinced. Yes, management is not always the positive influence it could be but an individual can start by writing unit tests that are only run locally, not automated and the rest of the team ignores. You only get some of the benefits of unit testing immediately but you get some. Once this starts being transformed into results then the weight of evidence should sway the rest (or at least some) of the development team and management will support initiatives that make them look better. Reduced issues and quicker delivery of changes achieves that...and unit testing can aid those.
Good quality initiatives tend to gather momentum.

I do agree that each individual has a responsibility to create quality code. And ideally, if a respected developer in the team uses testing, and shows how it actually makes it easier, that could lead the team to move towards more testing. But that really implies that the team already has weak management, and thus needs an internal, unofficial leader to make up for weak management and weak leadership. And that this unofficial team leader is now providing the management and leadership that they need and want. And thus we are back to the role of management. Not "Management" but "management."

The more you are prepared, the less you need it.