Question for staff: why no TDD?

whats TDD?

I'd imagine they haven't gotten around to it if it is truly essential in all work work environments. Me being uneducated in this, could you quickly describe why you think it's needed in their curriculum?

I had to Google it, because I didn't know either. Here is the Wiki definition. After reading most of it, I can see why it is not being taught. It may have been thought to be a "good idea" way back in 2005. But now...

After some reading, I find myself really agreeing with David Heinemeier Hansson that TDD is Dead

But this is just my newly formed opinion, and I don't see myself doing (or needing to do) TDD. (But like I said, just my own opinion)

:)

Personally I'm quite strict TDD, because that's how I've been taught. However, I'm aware that it's a spectrum that all developers sit somewhere on.

I'm yet to meet a professional developer who does NO testing. As for TDD (i.e. writing a failing test first, then writing the minimum code necessary to make it pass), the strictness varies amongst developers. And for good reason, but knowing when to test and not to test comes with experience.

In my fairly limited professional experience (I'm new to the industry), so far I've only encountered developers who are all for testing, and it's thoroughly integrated into their daily practice. I haven't yet seen a industry codebase that isn't thoroughly tested.

So to sum it up -in the industry, testing YES.... TDD varied, but mostly yes, in my experience.

Treehouse doesn't generally teach testing but I think they should. I dedicated myself to Treehouse's courses until I got to a point where I was left floundering due to not even knowing what testing was, let alone being able to do it.

I agree with Andrew (and would "upvote" his answer if the forum had that capability):

"Treehouse doesn't generally teach testing but I think they should."

They actually teach a little (and have dealt with TDD is passing)

but they need much more courses

(and more course material inside many of the courses) on this subject.

Hey everyone! Thanks for engaging in this discussion. All the teachers 100% agree with you on this that testing is an integral part of every curriculum. The question has been where to introduce it. We want to introduce it early enough to use and practice good habits, but not too soon that students aren't ready for it.

We now have (or will soon have) testing courses or workshops for:

• Java
• iOS
• Python
• Rails - TDD specifically
• JavaScript (coming soon)
• C#/.NET (coming soon)
• Android (coming soon)

Note that these are mostly unit testing. We made an explicit decision to teach some foundations of software testing first, and then loop back later with follow up courses or workshops on specific methodologies for things like TDD, BDD (Behavior Driven Design), or advanced testing tools (integration and automation). At this point it comes down to where each teacher or group of teachers has prioritized it in relation to other content in demand from students.

One of my takeaways here is that we need a better mechanism for discovering and voting on what is coming up. We have a roadmap available and should soon be able to plot out even further than the month or two we currently show on there. We just want to make sure things have accurate dates, and we're also constantly adjusting for the latest changes in each language or platform.

As for voting on upcoming content, we have a list of Trello boards, but it's a stop-gap solution until we can add such a feature directly into the Treehouse app. In the mean time, please use those boards, post in here, or email teachers with your content requests.

Good stuff. Thanks for responding. Personally, I think a great course to do would be:

• Build Rock/Paper/Scissors in pure Ruby using TDD (RSpec),
• Hook up to Sinatra to run in a browser, using TDD for Feature tests with Capybara,
• Deploy to Heroku. (all three in one course).

I would also like to see something like:

• TDD a simple pure Ruby 'Checkout' command-line interface.
• 'build a checkout to scan items', aiming for something like:

co = Checkout.new
co.scan(product_code)
co.basket
=> [array of product codes]
co.total
=> #whatever the total amount is, after promotions (eg 10% discount if total is over 25.00)

This is similar to a tech test I did recently, which led to a job offer.

Mainly, I think it's important to start with TDD-ing pure Ruby to build something like the above or rock/paper/scissors, THEN making the jump to hooking up to something like Sinatra, THEN deploying online.

THEN moving on to Rails, once you have a decent grasp of what's going on above.

And, of course, I think it's absolutely crucial that principles like SOLID are built into the pure Ruby parts. Those skills alone can land you a job (did for me). If you have some experience with Rails on top of that, it's a bonus, but employers generally want to see that you have a good grasp of coding design principles.

Also, for other students here:

It's important to remember that Rails is designed in a certain way to force you to follow these SOLID principles to a large degree, along with various other good conventions. It's important to DO these conventions yourself with something like Sinatra before moving on to Rails, so you understand the "why's". If you develop a good grasp of these "why's", you'll be able to be a good coder in any language, and developers will know that you're not going to write messy code that they'll have to spend half a day cleaning up and refactoring.

I would go so far as to say I know what I'm talking about, because this was my path:

• Started from nothing with Treehouse,
• Learned some Ruby then went on to Rails (with Treehouse), learned no testing or TDD,
• Nearly got to an employable standard, but plateau'd out, found it VERY hard to progress any further on my own,
• Bit the bullet and did a coding bootcamp (paid for it myself),
• There I learned what I've just talked about above,
• Got a job.

Amount of Rails required to get a job: very little to zero.

Knowledge of Javascript and other js frameworks required: very very little.

Grasp of SOLID principles and evidence of being able to write clean, test-driven Ruby code required, following good design principles (basically SOLID): Lots.

It also helps if you learn how to pair program (requires more Git), and if you can get some experience collaborating in small teams, even better, but you can get away without that.

Here's one tech test that led to a job offer (after a phone interview, the tech test and then 2 days in their office): https://github.com/Yorkshireman/promotest
(I was asked not to put the original specification online for this one, but I can tell you that they wanted to see TDD).

Here's another tech test that led to another job offer (similar process: phone interview, tech test, pairing session with a senior dev): https://github.com/Yorkshireman/bill_unattended
(notice that right at the bottom of the README, that the first two bullet points under "What we're looking for" are: "TDD/BDD", and 'Simple and eloqent code". )