Interested In SQL Azure?
Last chance today to register for tomorrow’s class:
[More information here]
SSWUGtv
with Stephen Wynkoop
New Show! Eric Johnson and Stephen Wynkoop on the show today talking SSIS, also the news of the week and Laura Rose is back with more tips for your career. Also, Stephen talks about important security steps with SQL Server. [Watch the Show]
Featured Article(s)
So, You Want to be a DBA? (Part 1)
So, you want to be a database administrator (DBA). You want to be in charge of the data of your company and realize that data is the lifeblood of any company.
TDD Compared to TFD
I was reading a nicely done blog by Ayobami Adewole regarding TDD. Mr Adewole did a nice job introducing TDD and unit testing. However, there was some confusion on his part regarding TDD and DFD. The only thing these two techniques have in common is the fact that they both perform unit tests.
Test First Development (TFD) is a technique for software development where tests are written prior to writing code. The tests may be written by the same person, or another developer may write tests. The key to this process is that you know the software is complete when all tests pass.
In this methodology the business requirements are often decomposed into modules, classes, method, and properties fulfilling the customer needs. UML diagramming is a common result of this kind of analysis. From these diagrams, a complete set of tests may be written validating customer requirements. All that must happen is the tests be written prior to writing the code, and code must be written completing all tests.
Test Driven Development (TDD), on the other hand works, directly from the business requirements. Developers work from the Business Requirements document rather than programming specifications such as UML diagrams.
In this case, the developer becomes the designer. Instead of designing in a CASE tool, the developer writes tests meeting a business requirement followed by code solving the tests.
For example, the developer may take a business rule that states a user may determine the precision for rounding a number using steps of precision up to .125. They may select from .125, .25, .375, .5 etc.
The developer will first write a test to perform this rounding by precision. Then they write a method solving the problem. At this point, when all the necessary tests have been written, they move on to the next requirement.
What happens using this technique is that the way the classes are designed, and the module layout will change, sometimes dramatically, throughout the process. This is much the same as what happens when you build UML diagrams. You find that there are better ways to layout your code. You might think this is inefficient because you will find yourself refactoring considerably. However, the efficiency is generally not any less than refactoring an UML diagram. In fact, it works more efficiently because the code is actually exercised through the tests providing a greater confidence in the ultimate design.
The real cost benefit is exercised due to finding errors in requirements and softare much earlier in the development lifecycle, resulting in highly reduced cost in writing software.
I guess you can see how passionate I am personally about software testing. I have so many war stories about tests saving time, or lack of tests resulting in expensive errors. So, I’ll put on my thick skin, and ask you to send me your thoughts, concerns, or experiences with testing in Email to btaylor@sswug.org.
Cheers,
Ben
Featured Article(s)
So, You Want to be a DBA? (Part 1)
So, you want to be a database administrator (DBA). You want to be in charge of the data of your company and realize that data is the lifeblood of any company.
Featured White Paper(s)
Office 365 SharePoint Online – what does it mean to my organization as a CIO?
Written by AvePoint
The goal of this white paper is to clarify the disjoint… (read more)