Very few people in the software development community have issues with maintaining good attention to the details. However, I bet those who live in the regulated software community view the “normal” software world as quite sloppy. Attention to detail is a matter of life and death for a medical device. Because of this, the entire software community does a good job maintaining checks and balances. I have three suggestions that will make a tremendous difference when you start a regulated project or when you finally get near to releasing your medical device.
Testing is a crucial part of all software development. If you don’t believe this you are likely just starting your career or haven’t had to support an application in production with users. It becomes doubly important in regulated environments like the ones for medical devices. This is because testing for regulated software serves multiple purposes. There is the usual software product development reasons to consider (i.e. professional integrity and no one wants a bug in production). But it is also because the FDA, in particular, wants to make
How many time have we heard some form of the phrase “it just a one line change”? Or “it shouldn’t effect anything else”?
I think we know the all to frequent result…..”I can’t believe THAT broke……!!”.
Good developers write automated tests to help surface side-effects like this before they get into production and cause real damage.
Good developer refactor code mercilessly to make modifications less error prone.
Good developers take the perspective that maintenance begin as soon as you write “just one” line of code.
Getting a version 1 product out the door is
edge case city: requirements and testing dates for HR business logic
We have an internal application that does staffing, time entry, and now Paid Time Off (PTO) accrual, scheduling and management. It is quite nice, as it has replaced three existing systems, and replaced a number of manual, tedious tasks. I started it last year, as our current system was very inefficient. It was a simple Ruby on Rails app that I was able to get working in a few weeks. Over time the functionality grew.
Ask Mr. Lizard, from Jim Henson’s Dinosaurs
It’s time to play “Ask A Tester Person”, where I answer questions that I’ve gotten via email or otherwise about Rails Testing topics.
If you have a question for Ask A Tester Person, send it to railsprescriptions at gmail.com.
Before I continue, I want to mention that Pathfinder’s own John McCaffrey and myself will both be presenting at WindyCityRails 2009, which is September 12th at the Westin Chicago River North. There are still some seats available for the main conference talks, registration is open until September
Rails Test Prescriptions, the eBook put out by Noel Rappin, Director of Rails Development at Pathfinder, has been picked up by Pragmatic.
Congratulations to Noel – he’s done a great job of furthering testing best practices in rails, and this is a great reward. As he said “I’m very excited by this. I’ve wanted to work with Pragmatic for as long as they’ve been publishing books, and I’m thrilled that this particular project will be able to get wider distribution and access to Pragmatic’s editorial expertise and skill.”
Here’s a minor thing that bugs me all the time.
I’m writing a functional test:
should “do something functional”
get :search, :order_id => @order.id, :user_id => @user.id
# and so on
The get call in that test simulates a browser request. Intuitively, you would (well, I would) expect this request to be identical to a request coming from the actual view, via a helper like link_to(“search”, :action => :search, :order_id => @order.id, :user_id => @user.id). At least, you’d expect that parameters hash in the controller to be the same between the
Frustration, the game, photo by unlovalblesteve
Dot, dot, dot, dot, dot — tests are passing, looks like it’s time for lunch — dot, dot, dot, dot, F. F? F? But the code works. I know it does. I think it does. Why is my test failing?
One of the most frustrating times as a TDD developer is that moment when a test is failing and you don’t know why, as opposed to the more normal case where the test fails as expected. Here’s a grab bag of tips, tricks, hints, and thoughts
Spam Wall, by freezelight
What with upward of two people saying nice things about last week’s post, I’ve decided to keep going with part two of a look at some real testing code.
Most code-heavy tutorials show the code but not the tests — I’m doing the opposite here, and showing the tests, but not much of the code. Also, although I’m presenting these tests in chunks, you should realize that there was a lot of back-and-forth from Cucumber to tests to code and some backtracking, most of which I’ll spare you
Spam Wall, by freezelight
As sort-of promised in last week’s post, I’m going to work through a real-world test example, with an eye toward explaining how and why I tested the way I did. Hopefully, I’ll be able to do this at blog-post length. If not, well, there’s always next week.
This site, which was a legacy rescue, allows users to send messages to each other within the site without having to give away their other contact information. The problem is that nefarious spammer types were creating logins and immediately sending messages