Test Driven Development And Other Paradigms

  • Testing
  • Coding
  • TDD

Apologies for not blogging the last week or two as frequently as I have been. It's been a hectic month. We finally got gas back on at the apartment two days ago, and it's so nice being able to cook again after four weeks. We also got gym memberships (blehhhh) and The Sims 4 (woohoo!). That said, I'll try to be more on top of the blog. Definitely expect some more recipes now that I have a functioning stove/oven.

Last night I went to a class at Galvanize called Introduction to Test Driven Development. I'm not sure how useful it was as an actual TDD intro -- I've never written a test in my life and I had to ask what the common testing frameworks were during Q&A -- but I thought it did a pretty good job of breaking down paradigms surrounding various test methods. Here are my notes.

Test Driven Development And Other Paradigms

Instructor: Sarah Spear

What is Testing?

Testing ensures that a component meets the requirements that guide its design and development, responds correctly to all kinds of inputs, performs functions within an acceptable time, is sufficiently usable, can be installed and run in its intended environments, and achieves the general result its stakeholders desire.

AKA it makes sure your code works.

Paradigms

Write Code, Then Write Tests

  • Tests are written after software is written to ensure it's working as intended
  • Ideal for prototyping and code that will go through many iterations
  • Gets code into production faster

No Tests

  • User testing with customer support tickets when things go awry
  • Might not think about edge cases

Behavior-Driven Development (BDD)

  • An extension of TDD
  • Tests the behavior of the system from the end user's perspective: What will happen under a certain condition?
  • Requires guidance from devs, testers, and users to answer the "whys" behind a user story
  • You do all of this first before you write your code
  • Can build acceptance tests, which determine if certain requirements are met

Test-Driven Development (TDD)

  • Product requirements are turned into very specific test cases, then the software is improved so that the tests pass
  • Tests the implementation of code functionality
  • Unit Testing: Test for just one piece of the software

Pros/Cons of TDD

Pros of TDD

  • Designs can often be cleaner and clearer than is achieved by other methods
  • Your applications are actually written for testibility
  • Ensures tests are written for every feature
  • Leads to a deeper and earlier understanding of the product requirements
  • Ensures the effectiveness of the test code
  • Maintains a continual focus on software quality

Cons of TDD

  • Requires substantial engineering resources
  • Tests must be changed when code changes
  • There can be a tendency to push engineers onto the next feature, even neglecting testing entirely
  • Can be difficult to know what and when to test

TDD Process

  1. Write a new test
  2. Run test to see if test fails
  3. Write minimum code to pass test
  4. Refactor code to maintain quality standards
  5. Repeat