“Unit tests are typically testing the logic within a particular method or group of methods and not anything else that those methods are and that includes external dependencies such as a database. So what we do is we write integration tests which are structured much like unit test to test those external dependencies to make sure that the code that you have that's making those calls out actually work correctly without error and then you can even in the case of database calls insert records into it in order to do your unit tests against let's say, read function to make sure that it's coming back correctly so it's doing what you intended it to do.” – Ed Bartam
Ed Bartram talks about “Assert Control Over Your Legacy Applications (TestBox Quick Start)” in this episode of ColdFusion Alive podcast with host Michaela Light.
Contents
Episode Highlights
- Why unit test?
- A unit is a method, function or small group of same
- Why do it?
- Refactoring is safer
- improving quality and reliability of their application
- Faster finding bugs when you change code
- Better deployment during your build process
- What is integration testing
- Testing logic vs testing external dependencies
- Functional tests with Selenium
- What TestBox?
- A test creation framework and scripting language
- Set up – before test suite is run
- Tear down – after test suite is run
- Before unit test is run
- After unit test is run
- Automated vs manual testing
- Good automated testing characteristics
- Repeatable
- Can be run at push of a button
- One test
- A suite of tests
- All unit tests
- Works with CI (eg Jenkins or Ant) so tests are run during your build process automatically
- Consistent test results independent of the environment (eg database)
- Full coverage of all code in the unit
- Independent of other tests – can be run in random order – no dependencies between tests
- Easy to detect if an error occurs and report on it so you can
- Test setup and tear down of dependencies
- TestBox does all the above
- Need to move code to methods or functions
- TestBox tips and best practices
- What tests to write
- How to name them
- Test_[method name]_[When to test]_[Expected enresult]
- How to write them
- When to write them
- TestBox color coding
- Tests that pass – Green
- Test that fail – Yellow
- Test that errors out – Red
- Result actions
- CI backout the deployment
- Slack
- Ring a bell via a Raspberry Pi
- Who broke the build gets to wear a special hat for rest the day
- Free open source
- Doesn’t require ColdBox
- Paid support is available
- CFML slack testing channel
- Replaces mxUnit
- Mocking and MockBox
- Spies and Stubs too
- Blackbox unwritten code
- Design patterns
- A test creation framework and scripting language
- What is a legacy application?
- Michael Feather book working effectively with legacy code
- Test Driven Development (TDD)
- Write a little bit of your test before your code
- Then write a little bit of code to pass the test
- Repeat
- Know as “Red-Green testing”
- How to install TestBox quickly in your existing environment
- CommandBox one line install of TestBox
- Or download and manually install
- How do we improve our code coverage then?
- which prescribes writing tests and then writing code to make those tests pass.
- Start with current bugs you are working on fixing
- First pull out the queries into methods and writer tests for them
- Second pull out logic into methods and write logic
- Could move to MVC – but not required
- CFMs = views and controller
- CFCs = model
- Why CFers resist writing tests
- Takes too long to writer
- Too hard to write tests
- Too late to write tests for existing code
- Why are you proud to use CF?
- WWIT to make CF more alive this year?
- What are you looking forward to at Into the Box?
Mentioned in this episode
- Michael Feather book “Working Effectively with Legacy Code”
- TestBox
- Selenium
- ColdBox
- CI
- CFML slack testing channel
- MockBox
- Test Driven Development
- CommandBox
- MVC
- Uma Ghotikar – Intro to Unit Testing, BDD and Mocking using TestBox & MockBox – ITB 2018
And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.
Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.
What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.
And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.
You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.
All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.
Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.
No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens Next
ColdFusion Alive Best Practices Checklist
Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.
√ Easily create a consistent server architecture across development, testing, and production
√ A modern test environment to prevent bugs from spreading
√ Automated continuous integration tools that work well with CF
√ A portable development environment baked into your codebase… for free!
Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.
Podcast: Play in new window | Download | Embed
Subscribe: RSS
Session Description:
Topic: Assert Control Over Your Legacy Applications with TestBox
Target Audience This talk is aimed at developers who work in environments having little to no code coverage with unit tests.
Description Developers are more confident making changes to code when it is covered by tests. Tests can be run as part of a business' deployment process improving overall quality. When starting a new “green field” project, this can be accomplished using Test Driven Development (TDD) which prescribes writing tests and then writing code to make those tests pass. But what if we already have a code base written with little or no tests? How do we improve our code coverage then? In this talk I will show you how to install TestBox quickly in your existing environment and how to get started writing tests improving the quality of your code and the dependability of your application. You will learn what tests to write, how to name them, how to write them, and when to write them. Attendees will be able to return to their office and immediately begin writing tests covering their legacy code, improving quality and reliability of their application.
Bio
Ed has been a ColdFusion developer since 2000, first using version 4.5. He is currently co-manager of the Chicagoland CFUG and previously co-managed the Nebraska CFUG in Omaha. While he has not spoken at a conference before, he has given several presentations to both groups. Ed has been a regular attendee of many conferences over the years including Devcon, Max, bFusion, CFObjective, Into the Box, and CF Summit. When he's not slinging code he likes to camp, hike, and work on his 1973 VW Beetle.
Links
Interview Transcript:
Michaela: Welcome back to the show and today we're going to assert control over you'll legacy ColdFusion applications out with a TestBox Quixtar and I'm here with Ed Bartram. And we're going to look at what is unit testing what is TestBox, what is he think a legacy application is anyway. We might delve a little bit ancestor of development. I'd look at how to install TextBox quickly and we'll look at issues of Cold coverage and what tests to write and all kinds of other best practices and tips and Ed is talking about this at Into The Box which is in less than a month's time our record date.
And just in case you don't know Ed, he's been developing in ColdFusion since the beginning of the McNally, since the year 2000 that say it that way when ColdFusion was backing version 4.5 and he's the Co- Manager of the Chicagoland CFUG and previously the manager of Nebraska CFUG, so he's got like lots of accolades for CFUG work in the ColdFusion community and he's also been to many ColdFusion conferences so, too many to name I would say. He is an owner, a proud owner of a 1973 Volkswagen Beetle. Probably runs on ColdFusion I'm guessing but, so welcome Ed.
Ed: Well, thank you Michaela. It's an honor to be speaking with you.
Michaela: So let's just start off, what exactly do you define as a unit tests?
Ed: Well, unit test basically test the unit. So unit is a small piece of code it could be a single message or function or even a group of message or functions depending on how you want to generate the tests. But units test will tests that unit of code and it will test all branches of logic to make sure that it works well and that it does what it's intended to do.
