
Ask HN: Getting started with TDD as a lone developer (without a job)? - ccajas
During a few recent job interviews, I&#x27;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&#x27;s used for but I don&#x27;t have any concrete experience with it. No single company I have worked for uses TDD!<p>It&#x27;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&#x27;m more familiar with those two languages.
======
qohen
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](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](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.

------
cr0sh
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.

------
cocktailpeanuts
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

~~~
ccajas
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.

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

~~~
ccajas
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.

