Geeks With Blogs

News profile for Aligned at Stack Overflow, Q&A for professional and enthusiast programmers

Donate Bitcoins

Check out Elapser from T3rse!
"free in Christ Jesus from the law of sin and death." Romans 8:2 (ESV) Check out the Falling Plates video on YouTube.
more about the Gospel
And then listen to Francis Chan speaking at LifeLight in SD.

Programming and Learning from SD

I’ve talked about and shown examples of testing with code (we usually say Unit testing) with fellow developers, but it seems that there is always a barrier to getting started. Here are some of my thoughts on helping you get past that barrier.

Notice that I avoided “Unit testing” in my title.

I break testing with code into several categories, that help me think and talk about testing.

  1. Unit
    1. Functionality of test directly, with dependencies removed through mocks or fakes.
  2. Behavior (BDD) 
    1. Test the expected behavior of one or more methods
    2. Think more in lines of the user
    3. Given x, When x, It Should …
  3. Automated UI
    1. Click through UI and verify output
    2. Selenium to test the UI in Web
  4. Integration
    1. Tests that use real web services, databases, devices, etc. to verify pieces work together
    2. Test database scripts can help ensure migration happens correctly
  5. System
    1. Test full system with multiple pieces end to end to ensure a user action can be completed.
  6. Performance
    1. Memory usage, Load testing
  7. User Acceptance Testing (edit from Bill Ayers comment)
    1. This can be automated or manual, but usually a combination of both. The BDD approach and/or User Stories can be helpful for this.
    2. “The key point about User Acceptance Testing is that it usually is a contractual requirement for customer sign-off and hence payment. This sets it apart from your own system tests in that it is usually the responsibility of the customer. In Agile processes it would be part of the "definition of done".” from Bill’s comment
    3. Check out the concept of a Deployment Pipeline in the Continuous Delivery book.
  • Read the Art of Unit Testing book and watch videos by Roy Osherove.
  • Read Test Driven Development by Kent Beck
  • Educate yourself on reasons why developers should consider writing code to test code. There are many links, but here is one from Roy Osherove.
    • http://www.slideshare.net/dhelper/benefit-from-unit-testing-in-the-real-world (slide 9 -11 especially
    • Here are some of my thoughts:
      • Continuous Integration and deployment depend on it
      • mindset change from developing and putting most of the testing responsibility on QA (devs are responsible for testing before giving it to QA or checking in)
      • helps when QA resources and time are lacking, these tests should result in faster manual regression tests
      • You don’t have to click through the UI every time you make a change, it’s faster
      • You have more confidence when you check in that you aren’t introducing regression bugs.
  • Think about testing from the outside in and use Behavior Driven Development principles to define acceptance criteria and behaviors before starting work. (see my post about some benefits of BDD). Build this into your development process and thinking, even into the requirements/acceptance criteria and testing, not an afterthought or they won't get done.
  • Write modular code following the SOLID principles and Single Responsibility Principle.
  • Use Dependency Injection to inject those dependencies.
  • Use a MVVM or MVC pattern for UI (KnockoutJS and AngularJS for web UIs)
  • Start with bugs as they come in. Squash them and make sure they don’t come back.
  • Determine what areas of your code are the most critical and easiest to test to decide where to start.
  • Run your tests in gated check-in builds and nightly builds. Don’t allow a manual test or release until all tests pass.

Useful Hints for Writing Tests

  • Comment your tests and think about tests with

// Arrange

// Act

// Assert

  • Test Naming: NameOfMethod_ItemOfTest_Expectation
  • Usually One test project per project.
  • MySite.Data could have MySite.Data.Tests

JavaScript

Use Jasmine

Use Karma to test on multiple browsers at one time

http://www.infoworld.com/d/application-development/your-quick-guide-better-javascript-testing-238249

UI

Use Selenium for web testing instead of CodedUI.

Consider using BrowserStack or SauceLabs to run your tests on their servers, instead of maintaining your own hardware.

Hopefully this helps you get started in the world of writing tests to test your code. Let me know if this was helpful or if you have more suggestions to add to this list!

Posted on Friday, May 2, 2014 4:42 PM Productivity , Unit Testing , BDD , Pragmatic Programming | Back to top


Comments on this post: A few hints to get started with writing code to test your code

# re: A few hints to get started with writing code to test your code
Requesting Gravatar...
I would separate system and acceptance tests. The key point about User Acceptance Testing is that it usually is a contractual requirement for customer sign-off and hence payment. This sets it apart from your own system tests in that it is usually the responsibility of the customer. In Agile processes it would be part of the "definition of done".
Left by Bill Ayers on May 12, 2014 7:59 AM

# re: A few hints to get started with writing code to test your code
Requesting Gravatar...
Thanks for the comment Bill. I've edited my post to include your comment.
Left by Kevin on May 12, 2014 9:08 AM

Your comment:
 (will show your gravatar)
 


Copyright © Aligned | Powered by: GeeksWithBlogs.net | Join free