I've always had a hard time coming up with a good comeback in conversations. It would be great to have a site where I could post a situation and have the community suggest and upvote/downvote insults and comebacks. Maybe introduce a real-time element so I could use it in an actual conversation.
I'm a product consultant who enjoys working one-on-one with entrepreneurs to take an idea, shape it into a product, and then build the MVP with Ruby on Rails. My projects are driven by regular communication and feedback from you.
* Consultation & Project Plan: $500
* Development: $2k/week, $500/day
---------------------
Rails Testing Consulting
---------------------
You don't write tests for your Rails apps, and it's starting to hurt. The time you dedicate to debugging mysterious errors could be better spent confidently adding new features. Unfortunately, you don't have the time to figure it out on your own.
I can review your Rails app and put together a re-testing plan, train you or a team on how to test, and work with you to re-test your app.
I'm a product consultant who enjoys working one-on-one with entrepreneurs to take an idea, shape it into a product, and then build the MVP with Ruby on Rails. My projects are driven by regular communication and feedback from you.
* Consultation & Project Plan: $500
* Development: $2k/week, $500/day
---------------------
Rails Testing Consulting
---------------------
You don't write tests for your Rails apps, and it's starting to hurt. The time you dedicate to debugging mysterious errors could be better spent confidently adding new features. Unfortunately, you don't have the time to figure it out on your own.
I can review your Rails app and put together a re-testing plan, train you or a team on how to test, and work with you to re-test your app.
1) is pretty hard, but I'm tackling some basic strategies to adding tests to an untested mass of code.
2) is the entire reason why I'm writing the book. Building a testing habit isn't as simple as following some basic tutorials. It's a fundamental shift in how you think about writing code and can't be summed up in a 5 minute blog, like you say.
To address your software, the answer is a little stretchy. For the code that depends on device data, you simulate as little device data as possible needed for your code to work. This means that if you have a method that only needs a device id, you only provide a device id. If you have a method that generates a report, you provide all the data that is needed in the report.
Another approach would be to try to group the test data together into common traits. I don't know enough about your software to come up with some examples, but you likely don't need to collect test data for every single device, but instead data that is representative of every single device.
If you want to find me on the twitter (@genericsteele), we could keep this conversation going. I'm interested in how you see the world of testing and just this thread has helped me think of new perspectives. I would love to figure out you could overcome the obstacles your work is throwing at you.
1) Inheriting someone else's bad code and habits is a huge reason to throw testing out the window. It's really frustrating and always comes with a "We'll write tests in the future."
2) This goes in line with another thing I've been finding. It's super easy to show why you should test, but It's much harder to actually show how to test in the real world. These tutorials show the simplest way to write a test, and it hurts those trying to learn.
A year ago, I would have agreed with you. There's nothing stopping you from building a successful product without writing tests. Since I built the habit of writing tests, though, It definitely makes a difference, especially if you're working with a team or contractors.
Tests are a super helpful way to say "See, this works. Make sure it keeps working, everyone."
Computers don't understand english very well. It's easier for us to learn to talk to them, than to teach them how to understand us.
DSLs are helpful for some, but sometimes they get in my way. A good example is formtastic (http://github.com/justinfrench/formtastic) in ActiveAdmin. I already understood forms when I had to implement this, so it just dragged me down.
If using a DSL makes your life easier, by all means use it.
"For me it was a simple decision: If I want community support, I need to be using the tool the community is actually supporting."
Truth. And the community is really split on this one. The side that makes the decisions about what goes into rails prefer unit tests, while a large chunk of the users prefer spec-based.
My theory is that new Rails developers spend more time learning how to test than what to test. This article isn't necessarily about which framework is better, but more about which is better as a testing learning tool.
It's been pretty cool working on the testing book because I'm approaching it from a different angle. I'm not testing something, I'm showing someone how to test. I've got to dig into Test::Unit and MiniTest more than I ever have, and it's been great.
There isn't a wrong way to test, so long as tests are being written.
I don't recommend MiniTest::Spec for the same reason I didn't recommend Rspec. It requires some extra configuration out of the box. The actual process of switching from Rspec to Test::Unit went Rspec -> MiniTest -> Test::Unit. There's just more stuff that's neccessary to start writing tests.
It's the same reason that new rails devs shouldn't swap out ERB with HAML before they build their first application. Get to know the defaults, then decide.
This is great. Two weekends ago I did the same type of migration using Linode and Capistrano. Heroku taught us what we should expect from a platform, and it seems like, as a community, we're moving towards getting those great features ourselves.