codedtested

"The main advantage of this technique over the use of instance variables defined in a setup method or before block is that the setup logic can be divided into smaller units and executed only in tests where they're needed."

from http://chriskottom.com/blog/2014/10/4-fantastic-ways-to-set-up-state-in-minitest

Refactor only tests or only production code... not both at the same time?

talk-integration-tests-are-bogus

Don't use refutations

http://thomascannon.me/posts/porting-to-minitest-part-1/

Collaboration tests, interaction tests

35:30 in integration tests are a scam collaboration tests, interaction tests (as opposed to state-based tests)

On the other side of these are the contract tests. (J.B. Rainsberger's terminology for these... what is Sandi Metz's?)

Refactoring a test suite

Two good ideas from this blog post

http://thomascannon.me/posts/porting-to-minitest-part-2/

"Only work on one type of test at a time"

"Functional tests are different than unit tests, which are different than integration tests, and so on. By only focusing on one type of test at a time it's easier to get in a groove and crank them out. And splitting the team up to work on different types of tests makes the porting faster and makes sure you don't step on each other's toes."

"Only work on one file at a time"

The quickest way to be overwhelmed and not make any progress is to run:

Instead, work on files in isolation:

ruby test/unit/user_test.rb

Adapters (and how to test them)

Article here: http://blog.arkency.com/2014/08/ruby-rails-adapters (haven't read it yet)

Tests communicate

A spec, much like a well named method, can show that you gave consideration to something. An example is the very wide and very tall images that Kaushik was trying to get to work. Looking at the tests, it was clear they hadn't been considered, because there weren't tests for them.

speed up tests by removing them. remove them by abstracting gems

You don't test all of Rails when you run your test suite. Maybe there are hidden gems that could be pulled from your app, which would allow them to not be tested with you app anymore, just like how Rails isn't tested with your app.

blog-post-first

....

But nothing makes code easier to change than a quickly executing suite of tests that you trust -- nothing.

Is testing dead? (a little different from "is TDD dead?")

Uncle Bob Martin writes: http://blog.8thlight.com/uncle-bob/2014/05/19/First.html

In the first Is TDD Dead? hangout, at time 30:25 @dhh makes a remarkable statement:

"...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."

So, of course DHH thinks of testing as professionalism.

The difference between mocks and stubs

over-testing

Something that DHH thinks happens (four lines of tests for every line of production code... 200% coverage). Kent Beck argues that it's actually high-coupling that's the issue, really, so you have to change too many tests when you want to change code.

TDD works well for a world of constrained inputs and outputs. If we can turn a problem into that world, it's very easy to test.

Isolated testing

the TDD is dead meme

For less experienced developers:

inexperienced developers doing TDD tend to not refactor enough

inexperienced developers doing TDD may not create great code, but they do create regression tests, which will help when changing the code to make it better later

TDD is good for a less experienced developers because it forces them to do things in a bite sized fashion that a more experienced person might do just because of experience

The limits of TDD

What TDD won't help you do...

http://blog.extracheese.org/2009/11/the_limits_of_tdd.html

TATFT

http://smartic.us/2008/08/15/tatft-i-feel-a-revolution-coming-on/

The problem with factories

blog-post-time-to-bring-back-fixtures

blog-post-test-induced-design-damage

The problem with fixtures

Self-testing code

Martin Fowler talks about this... as either being done with TDD or with tests that are written after the fact.

Feedback so fast you can't think

I" want my feedback to be so fast that I can't think before it shows up. If I can think, then I'll sometimes lose attention, and I don't want to lose attention."

from https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric

100% Time to learn

TDD is useful and test isolation is useful, but they both involve making trade-offs. Unfortunately, doing them 100% of the time seems to be the best way to learn what those trade-offs are, and that can temporarily lead beginners toward extremism. TDD and isolation both break down in some situations, and learning to detect those situations in advance takes a lot of time. This is true of advanced techniques in any discipline, programming or otherwise. That is the honest, non-exaggerated, no-lies-involved truth.

from https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric

classical TDD

means TDD without isolation (from https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric)

Simplify requirements to reduce complexity to reduce surface area required to test

Quoted from here: http://parley.rubyrogues.com/t/dhh-descrying-the-death-of-tatft/2067/7

characterization tests

talk-therapeutic-refactoring

Why is mocking any_instance bad

See the rspec documentation... supposedly they talk about that.

Avdi Grimm says in this thread: http://parley.rubyrogues.com/t/dhh-descrying-the-death-of-tatft/2067/29 : Can we all just agree that any example of mocks that uses any_instance is by definition a bad example of using mocks?

He points to this thread: http://parley.rubyrogues.com/t/any-instance-why-all-the-fuss/1998

Why the speed of tests is so critical

case transaction loop

Mentioned here: http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

Isolate occasionally failing tests

Testing to an interface (the Sandi Metz book) (AKA, how to deal with the problem of mocks)

Why I don't test controllers

Functional core imperative shell

"extract a functional core wherever it was natural, testing the core in isolation with no test doubles at all"

It's like how using only POROs allows you to have a much more complicated system under test, and to test all the interactions between all the components quickly.

My experiences with cucumber

blog-post-how-we-write-readable-feature-tests-in-rspec

Selenium

How to build testable JavaScript

Cross-platform and future-proofing benefits of test isolation

Test spies separate stubs from verification

Fast tests can be more abstract because you can test after tiny changes.

How tests serve as a positive design pressure on code

And finally, acceptance tests handle happy-path user interactions.

Different types of tests either facilitate or hinder change at different levels.

High level acceptance tests facilitate sweeping architectural refactoring, but are not great for enumerating behavior. Low-level unit tests are great for facilitating the continual accretion of new constraints while protecting against regressions, but can hinder your ability to make large changes, since you have to pull them along for the ride.

Testing as spikes (part of the remove tests after covering them a better way idea)

How to push for a testing culture

http://nerds.airbnb.com/testing-at-airbnb/

"listening to the tests"

Paying attention to your tests being hard to set up... Originally from GOOS? (They mention that they call it "listening to the tests", but did they coin the term?)

blog-post-writing-sensible-tests-for-happiness

blog-post-how-to-test-multithreaded-code

People

person-gary-bernhardt person-kent-beck person-david-heinemeier-hansson person-j-b-rainsberger