Ask HN: Getting started with TDD as a lone developer (without a job)? | Hacker News Reader

Ask HN: Getting started with TDD as a lone developer (without a job)?

1 pointccajas6 comments

During a few recent job interviews, I've gotten the impression that most companies have hit warp speed in development practices, compared to the last places I worked for. They ask me TDD-related questions. I know vaguely what it's used for but I don't have any concrete experience with it. No single company I have worked for uses TDD!

It's one of the many things that is keeping me from getting my next software engineer offer (and working as SDET is out of the question obviously). So where to get started with it? How do I know which testing framework to choose? For reference I want to use it with JavaScript and C# as I'm more familiar with those two languages.

View on HN

Not the right languages, but if you want to see TDD being done, deeply, there's a guy, Brett Schuchert, who has some very detailed videos where you watch him do it and he explains what he's doing and why.

He has an 11-video series on using TDD in Java to create an RPN calculator and a 3-video set for a C++ dice-game example.

(I suspect it might be helpful to duplicate his setup and to actually follow along, doing what he's doing, to really get the full mileage and not just to passively watch.)

Again, not the languages you are interested in, but once you get TDD in your head, I expect translating the knowledge to other languages/test-frameworks would be pretty easy. (As to which frameworks to choose, you can probably Google that up pretty easily).

His video albums of this stuff are on Vimeo here:

https://vimeo.com/user3159463/albums

P.S. If you Google: site:youtube.com TDD C# (or Javascript) or site:vimeo.com TDD Javascript (or C#) you'll find a whole bunch of videos.

Here's a 2 hour C# TDD video: https://www.youtube.com/watch?v=pzonnSyqVfc

On Vimeo there are many videos too, including a Javascript TDD of Fizzbuzz and also a TDD calculator kata.

Again, might best to do it along with the presenters and not just watch the videos.

Good luck.

If you're going to learn TDD - then I suggest you learn who "Uncle Bob" (Robert C. Martin) is.

Watch a few of his videos, read his blogs, etc - it will all become clear.

It will also sound completely insane, if you are already used to coding and writing tests.

But give it a shot. Once you get past the awkwardness of it, you will be amazed at how well it works.

Is it the be-all-end-all for testing and development? No - it isn't. But if you're going to learn it, getting it from Bob is not a bad way to go about it.

I think a lot of companies write tests nowadays but only a small number of them actually do true TDD.

TDD can be actually counter-productive unless you have a very clear spec, which is never the case. There's a reason why TDD is evangelized by agencies.

That said, I think it's good to learn testing just for the heck of it, you'll get used to it after you start writing a few. For JS try mocha

Thanks, I'm gonna try out Mocha. I think it was briefly mentioned for a coding test I once did.

I have worked for two web agencies (we do mostly CMS re-skins and custom websites for small clients) but TDD isn't really pushed there. Nobody talks about automated testing or writing tests.

Our QA does all the testing, to give us the thumbs up (or down) that it's good to push the code to the master branch.

Managers just expect the developers to finish the tasks given from a certain deadline and lack the technical knowledge to give input on how to improve the development process. If you tell them that we need to write tests, they will ask, how does that increase customer satisfaction? Because of this I believe that the need for TDD, or even just writing tests is a hard sell at many companies.

It sounds like you need to learn how to (programmatically) test your software, not learn TDD. Have you written tests before?

I haven't learned or found a use for writing tests. It seems like it only comes into its own with large code bases, where I don't have much experience in.

It's not really something that was talked about or used at my previous jobs, either. We just had one QA guy doing manual testing whenever we notify him that a ticket has been resolved.

Reply on news.ycombinator.com