Thursday, April 10, 2008
Test Patterns - recurrent design patterns in testing

We all know what design patterns are in software design and development. These kinds of patterns also are recognized in unit and other kinds of tests as well.

While it is not necessarily a new idea, it is a good idea. Here are some links I have found on the subject. Further research should yield a whitepaper soon, if I ever get time to write it.

Brian Marick's testing.com: http://www.testing.com/test-patterns/patterns/

A great example at CodeProject: http://www.codeproject.com/KB/architecture/autp5.aspx

RBSC: http://www.rbsc.com/pages/TestPatternList.htm

TypeMock Unit test patterns for .net: http://www.typemock.com/Docs/TestPatterns.html

Book: xUnit Test Patterns: Refactoring Test Code

Enjoy

Thursday, April 10, 2008 7:20:14 AM (Pacific Standard Time, UTC-08:00)  #    Comments [1]  |  Trackback
Tuesday, April 01, 2008
Acceptance Test Driven Development, Explained

Acceptance criteria should be our measuring stick when we write software. These criteria should give us the direction to go in writing features, and ultimately the final answer on whether the software is "done" or meets the customer's need. When the customer (or the customer representative, product owner, or business analyst) gives us a notion of what the software is to do for them, it represents a guideline and a goal for our development.

  This article is a discussion of ATDD in an Agile development context with Scrum project management and Extreme Programming [XP] development methodology. However it does not apply specifically to Agile. These same techniques can be applied with almost any mechanism.

  Test-Driven Development [TDD] says that we should first write a test before we write the code. This forces us to understand clearly what the code is to do, because we have to write the test to verify it. Writing the test is usually the hard part - the code next is easier. This is where the discipline of TDD is most needed. The test itself should be failing when executed, since we don't have the code under test [CUT]. This is a good sign - we need to actually "test the test." We then write as little CUT code as needed, just to make the test pass. Then, we start all over again - write a test, some more code, etc. We refactor the CUT as needed, to make it a cohesive, maintainable design, while still keeping all the tests passing. In this way, we have a complete test framework wrapped around our high-quality code, which makes certain that the code always functions the way we intended no matter what kinds of changes we make internally to it.

  This process of TDD as described, is the traditional mechanism we now refer to at Unit Test-Driven Development, or UTDD. There are higher-level tests that we can write also, that have the same impact on our development process. Applying this same concept of a failing test driving us to write code is where this discussion now leads, but at one level of abstraction higher. We now look to the Acceptance Criteria to drive our TDD, or now ATDD.

  1. Acceptance Criteria gives us a target for writing Automated Acceptance Tests [AAT's] a. Acceptance Criteria need to be written into an executable set of automated tests. b. AAT's should be able demonstrate to the customer that their criteria for the functionality has been met. c. Ideally, this should include as much detail as the requirements bear out, and as many tests and checks are necessary to convey that each of the criteria has been accounted for.

  2. AAT's give us a reason to write code (they are failing - no CUT yet) a. AAT's can be written before writing the code, or written one at a time following this process.

  3. We now write the empty framework for the CUT. Some AAT's may still be failing, but that's OK. a. This step deviates from strict TDD in that we are writing code, but not for the intent of passing a test. b. One example is that if a criteria states that a customer is able to bring up a web page with a set of information, obviously we need to provide a web page. c. This framework concept is creating the empty page or container for the code we are going to write. d. The empty framework should not cause AAT's to pass, because AAT's should written to test at a higher level of functionality.

  4. To make the AAT's pass, we need to start providing the functionality inside the empty framework. Here we need to apply the standard TDD concepts, and write a failing unit test.

  5. We now have a failing unit test, so we write enough CUT to pass that test.

  6. We repeat at step 4, refactor, and continue following the UTDD process as described above.

  7. When the functionality that the AAT's require is there, they will be passing, Unit Tests [UT's] are passing, and our story (feature) is complete. We now continue to step 1 again for the next story.

  How do I do it? What do I need to get started?

Acceptance Test Driven Development is a practice that can yield good returns on the time invested. Customers will be pleased with the software they receive, bugs will be fewer, and delivery times will be shorter. However, there are a few things that are needed to make this practice effective in an organization.
  1. Buy-in
    1. People must be bought-in to the concept that test driven development is a good thing.
    2. Management must support this practice, for if not, it will be a much more difficult thing to accomplish.
    3. Developers must be willing to put aside their "classical" training and try something new.
  2. Testing Tools
    1. If we can't write an automated acceptance test for our product, we can't do ATDD. We need a tool designed for testing the particular type of product we are shipping.
    2. Story Test IQ [STIQ] is a great tool for automated testing of web applications. Straight Selenium RC under C# code, driven by NUnit also works great, in my experience. VSTS has some good tools also, as do Fiddler, and probably lots of other products.
    3. The framework must be in place on day 1 of the iteration to begin writing acceptance tests. If it isn't available, we won't be able to do ATDD.
  3. Skills
    1. Developers need the skills to be able to envision what is to be delivered, and be able to write automated test scenarios for the acceptance criteria.
    2. Testers need to be able to validate that the tests cover enough of the functionality through testing the criteria, and provide other functional, integration, load, and performance tests in addition to the developers' unit tests and acceptance tests.
    3. Management needs to be able to direct the right resources at tasks, no matter whether they are Development or Test tasks. Sometimes it's best to blur the lines between the disciplines to make this practice most effective.
    4. Customers need to be aware that they are actually going to get what they specify (and perhaps ONLY that much). Education on criteria evolution is almost always required for customers. Don't be surprised if only 50% of the criteria are discovered in sprint planning and story generation for the first couple of iterations.
  4. Experience
    1. TDD takes discipline, and ATDD even more so. This is not a practice for an organization just beginning down the road of TDD. Put in at least 6 iterations of using strict TDD first before trying ATDD. The experience gained with using TDD will naturally flow into ATDD, and the organization and the customers will see the benefits.
  5. Perseverance
    1. Good things don't happen instantly. It takes some time to see the benefits of ATDD.
    2. Be patient for a few sprints. It should take approximately three iterations to get it dialed in.
  6. Customer Cooperation
    1. Customers must be available for providing their criteria for acceptance.
    2. Customers generally are not experts in this type of "specification" of criteria, and must often be helped through the process at first, to generate usable criteria.

ATDD | TDD | Testing
Tuesday, April 01, 2008 10:10:03 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Sunday, March 23, 2008
Testing? Aren't I a Developer?

Aren't developers just supposed to write their code and let the test team test it?

ahem.

no.

As a developer, I take pride in delivering *working* software. If I don't test my own software, I think that I'm really failing to do my job. Testing is not just for "testers."

As a professional software engineer, I need have not only unit tests for my code (a Development practice by the way), but I also need to write automated functional tests to make sure that all the functionality works as I think it should. Then, I need to have automated Acceptance tests that tell me if indeed the whole system works together to deliver the business solution that the story or requirements describe.

Acceptance Tests
  Why do I start with acceptance tests?

Because... they should drive the entire development process. Test-Driven Development doesn't necessarily have to *always* mean Unit Test-Driven Development...

The Acceptance tests drive me to write code.
In order to write code, I need a unit test.
Then I can write the code that passes the unit test and the acceptance test.

job well done.

Unit Tests
  I write enough unit tests to be able to make sure that the functionality I write works as I intended. Not too many - tests require maintenance as well as the code they test - but enough to ensure that it's safe to refactor just about anything in the code and make sure that it still works as intended. This is the safety net that unit tests provide.

Code
  Write some. It should make the tests pass. Failure is not an option.

Functional Tests
  We need to make sure that all the pieces of functionality behave in a known way. This is what functional testing does.



Integration Tests
  We need to make sure that all the systems co-operate. Integration tests are deeper yet than functional tests, these are more like "end-to-end" tests of particular scenarios. Usually these scenarios cover all the happy paths of end-to-end, and most likely a couple of failure scenarios as well, to illustrate how the system overall behaves in failure modes.

Deployment Tests
  You DID want to INSTALL the software and use it, right?

So... you got a test for that?

Sure you do.

Deployment tests are essential for making sure the software delivers and configures the binary bits in a way that's useful to the user. Uninstall is a particularly critical issue as well. Make sure that you have complete testing around these critical fundamental features of the software.

ATDD | TDD | Testing
Sunday, March 23, 2008 9:47:08 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Tuesday, March 18, 2008
Teaching TDD, and Advancing the Practice

Advancing the Practice

Better unit testing. Mocks. High code coverage. Fast test suite execution.

What are some of the things we need to get to these goals?

Teaching TDD

Some developers have an open mind to learn TDD. We need an effective mechanism to teach them the skills of how to think test-first in a fairly rapid manner. TDD is not just about test-first, it's about code quality. To ensure code quality, we need good tests. If your developers aren't writing good code, chances are they are writing even lower quality tests, if any at all. How do we get good quality tests that make sure our code is in good shape?

Test authoring, like most things in life, requires skill, and above all - Practice.

Take some well-written unit tests, and go over them with your developers. Teach them about the parts of each test, the setup, the test, and the assertions (and cleanup). Show examples. Have the experienced developers review the unit tests the other developers write. Have your test lead review unit tests too.

TDD
Tuesday, March 18, 2008 9:44:35 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Friday, March 14, 2008
The Evils of DDD
(No, I don't mean Domain-Driven Design.)

Ah, but haven't we all seen the results of Date-Driven Development in action. Don't let this happen to you.

Report all non-agile software development practices to your local scrum master. http://UnScrum.com


Friday, March 14, 2008 9:40:51 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Thursday, March 13, 2008
ATDD - Acceptance Test Driven Development

Use ATDD as an advanced extension of TDD, keeping the software's development guided by the principles of satisfying the customer's needs through acceptance criteria and automated testing.

BDD, ATDD, UTDD, DSL's ... when will it all end...

The drive toward business-driven testing has never been stronger. Developers are seemingly now finding a higher and higher bar when it comes to customers' expectations of quality and features. Our tools are getting better, and we can deliver more software, faster. But, our methodologies haven't necessarily changed enough to satisfy today's customer expectations.

Enter Business-Driven Design...

Business driven design is a concept that enables us to take business requirements and current priorities and turn them into a software design through Acceptance Test-Driven Development. The business requirements that drive the need for the software are turned into specific criteria that allow the business to decide what the criteria are that will allow them to use a feature and have it meet their business need. Rather than the old-school way of gathering requirements, and having a requirements document and a functional specification, we now turn to individual small criteria that decide if the software is acceptable to meet the need. Some of the criteria map directly from functional requirements, and others may not have been captured in a traditional requirements gathering and specifying model.

Domain-Specific Languages (DSL's) are key to success in Acceptance Test-Driven Development. DSL's give us a way to communicate with the customer and domain experts in their terms. When we capture criteria in this manner, it becomes quite clear to those with domain knowledge, what is meant and what is desired. There is no need for a "translator" between the customer and the developers (this used to be called "Business Analyst"). The developers model the code in terms of the language the customer already uses. This mechanism leads to better communication, better encapsulation, and better object-oriented development.

Acceptance Test-Driven Development [ATDD] gives us a mechanism to use DSL's and direct customer involvement in making sure the software we deliver meets the needs. When we take the criteria and turn them into automated acceptance tests, it is far easier for the customers to see that they are getting what they asked for. It's also easier for the developers to have a target to shoot for, and have a goal to meet. This way, they are more focused on delivering a specific unit of functionality that the customer needs rather than (as so often happens) some "new feature" that they thought might be useful.

Much care needs to be put into the way that acceptance criteria are gathered and then automated. If there is something that is missed, it could critically affect the design. This is an opportunity for customers and developers to collaborate and get it right. The customer needs to understand that if it isn't on the acceptance criteria list, it isn't going to be in the software... Performance criteria, interoperability with other systems, and other criteria like these are often missed. Customers should have many opportunities to review and re-review the criteria before they are approved. Even still, sometimes things are missed. This is why it is important for the customer to be involved at all stages of the development process. The customer shouldn't just be involved in the criteria gathering, then come back later for their product. If things are missed, they will likely become apparent and turn up in daily work. If the customer is there to be consulted, decisions can be made about how to integrate missed criteria, and how to capture these better in the future.

Business-Driven Design is a business-centric, collaborative, agile mechanism for delivering quality software to today's demanding customer.

TDD | ATDD
Thursday, March 13, 2008 9:39:09 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Monday, February 11, 2008
Red, Green, Refactor
Describing the rhythm of the TDD cycle
Read more ...
TDD
Monday, February 11, 2008 11:17:18 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
About TestDrivenDeveloper.com

Test Driven Developer


Assert.AreEqual(13, stripes);
Assert.AreEqual(50, stars);
seems like enough tests to me...

NOT!

Welcome to Test Driven Developer! This site is dedicated to those who understand the benefits of test-first development, and the advancement of the practice.

  It is sometimes hard to convince traditionally trained developers that it is better to write a test first, before writing the code. In Test Driven Development, we always write a test first before writing the code.

Many developers are hard to convince to use this methodology. It is very often difficult for a developer to understand completely what the code needs to do. Yet - they want to proceed to write it anyway? It's kind of a flaw in the thinking process.

Lucky that you are smart enough to know that there's a better way..

TDD is not a Java thing. It's not a .NET thing. It's not language dependent. Anyone can do test-first development, for literally any kind of software development.

Figuring out the test for some code is always the hard part... that's why we like to do it first, and get it out of the way.

TestDrivenDeveloper.com is a John E. Boal web site. Please see also my personal blog and my Agile Development blog

TDD | Testing
Monday, February 11, 2008 10:33:29 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
Monday, January 14, 2008
Testing SQL Tables
Have you ever wanted to test a table in the database for the correct structure? Ever had someone make a column nullable that shouldn't have been? ever have someone make a column VARCHAR instead of NVARCHAR? INT instead of BIGINT? SMALLDATETIME instead of DATETIME? This is an easy way for bugs to creep in - when the code is written for one version of the database and then someone makes a change... So if you haven't been testing your tables (SQL should be TDD'd too), perhaps you should...
 
Here is a handy stored procedure you could use that describes a table in an easy-to-test way.
 
CREATE PROCEDURE describe (@table_name varchar(90))
AS
SELECT DISTINCT
  sc.column_id as ColumnNumber,
  cols.column_name as Name,
  cols.data_type as Type,
  ISNULL(cols.character_maximum_length, 0) as Length,
  cols.is_nullable as Nullable
FROM

  information_schema.columns cols

  INNER JOIN sys.columns sc ON

    cols.column_name = sc.name

    AND OBJECT_NAME(sc.object_id) = @table_name

ORDER BY sc.column_id
 
Just call it with the table name and it produces a nice format the tests can use to extract the info they need to check.
 
# Name         Type     Length Nullable
1 Id           int      0      NO
2 TypeId       int      0      NO
3 Name         nvarchar 50     NO
4 Description  nvarchar 1500   NO
5 CreateDate   datetime 0      NO
6 UpdateDate   datetime 0     YES

just employ a data reader to read the data in the test, and your unit tests can ensure that all of the tables have the right structure.
SQL | Tools | Unit Tests
Monday, January 14, 2008 8:15:53 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  |  Trackback
© Copyright 2012, John E. Boal