1–10 of 24 posts
They say it's because they wanted to put something out there rather than focus on testing. Is that legit?
I like them a lot, but it makes me nervous that they don't have any test framework in place. I think they're open to testing now they are more stable. Thoughts?
If they've been working at it for a while, joining them is going to be a lot hard work. For one, it can be a warning sign, in the first place, their code will be hard to test. Dependencies will be out of this world, who knows where they put their business logic, random classes doing random things, random database session handling, god objects, and other elaborate hard-to-maintain hack stacks.
If you still want to join them, introduce testing to them by creating tests for one small part of their stack, it will easily show off the merits of testing:
- It's not just about putting something out there faster, it's also about failing business assumptions and the capability for your code to iterate/pivot quickly. Testing helps you in that aspect. Spend 10 minutes running the entire stack and tracing where a bug occurred, or just run your tests and find out what went wrong.
- The great thing about automated tests is that whenever I make huge changes in my code and the tests still run it means I can confidently say I didn't break anything at all. If I did, then I can easily know where and how, and I don't have to run through the entire app. I could easily isolate a single piece of my stack and test directly.
- Testing forces the team to write maintainable software.
- Another amazing meta-feature about tests is that, whenever you're debugging, it takes a huge chunk of business logic out from your cognition. You don't need to carry the extra cognitive load that 'x' part of your stack be able to 'y'.
Anyway, join them not for the sake of their code, join them if you just love what they're doing. You'll work through it.
In the even slightly long term, tests don't slow things down, they keep things fast. It is MUCH easier to change and maintain code with good tests. Think about it this way: when you write code, you damn well better be testing that it works as you write it. Why not test it with other code, and save that so that other people don't have to do it over again? Manual testing is slow, error prone, and very expensive. Better use it judiciously instead of making people track down stupid programming errors that could have been caught in 7 seconds with a decent unit test suite.
TDD is overrated and overused, with no regard for the cost of developing/maintaining the test suite. You should join them -- you will probably learn something about building correct software, such as "automated regression testing is not the only way". Ironically, tonight I have fired up the RT I use for one subsystem because it needs work. ie, RT has its place, but the TDD crowd thinks every place is that place. btw,…
TDD is overrated and overused, with no regard for the cost of developing/maintaining the test suite. You should join them -- you will probably learn something about building correct software, such as "automated regression testing is not the only way". Ironically, tonight I have fired up the RT I use for one subsystem because it needs work. ie, RT has its place, but the TDD crowd thinks every place is that place. btw,…
If they're only starting out, it would be okay if there would be no testing at first, but as the months roll by, they'll need testing sooner than they think. If they've been working at it for a while, joining them is going to be a lot hard work. For one, it can be a warning sign, in the first place, their code will be hard to test. Dependencies will be out of this world, who knows where they put their business logic,…
I talked to a very hot startup (100M+ valuation, very solid business model) that everyone here has heard of, and they had no tests at all.
Don't discount a company because of their testing situation. Heck, maybe you'll be the first engineer to start writing tests!