Technically, I currently work for a well-established company. Workforce-wise, they’re not huge but their operations are significant. Couple that with the fact that they deal primarily with banks, and it’s no surprise that their process is very “enterprisey”. Luckily, I don’t “really” work for that company. I’m the CTO of a much smaller “startup” that’s being seeded by the owner of said larger company.
It’s so funny to talk with the C# and Java developers from the parent company because they just don’t “get” how we work. For instance, testing. We’ll be consuming their services via a SOAP API (I said they were enterprisey). Today, one of their devs came by my office to talk to me about the various error conditions and codes in their API. Some of them will be newly created in their system specifically for how we’ll be using the system. The developer assured me that they’d get them implemented as soon as possible so I can start to test my logic for handling them.
I told him not to worry and assured him that as long as the service will match the specs, then I can start writing and testing my code before they get finished building it.
“But how can you test hitting our service if it’s not built?”
“Oh, I could do it a bunch of ways but I’ll probably just stub out the calls with webmock or something. Even after the service is built, most of our tests won’t actually hit the service anyway unless I delete the VCR cassettes.”
blink blink…stare…what…I don’t…did he just say VCR cassettes?
As he was walking away, I swear I heard him whisper under his breath, “That dude’s crazy”.
One of these days, I hope get a minute to sit down with those guys and show them how we run tests. Until then, I guess we’ll just have to live with being those crazy kids down the hall.