69. the test with arcane terminology
name/descriptor should say it all
70. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation
71. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation
people rolling onto a project <3 you for it
72. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation
people rolling onto a project <3 you for it
comment = well named test
75. The slow test
too much data ? (again, fixtures or heavy setup)
up next..
76. The slow test
too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
77. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
78. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
79. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!
80. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!
Rails startup time !@#$?
81. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!
Rails startup time !@#$?
Spork, Guard
83. The test that has complex setup
Fixtures are for static data only
84. The test that has complex setup
Fixtures are for static data only
Large factory setups are better than invisible fixtures
85. The test that has complex setup
Fixtures are for static data only
Large factory setups are better than invisible fixtures
Stub non essential factories
91. Avoid redundant / replicated tests
Push tests down the order as much as possible
e.g. Controller tests that can exist as model tests
Rule of thumb : Do this as long as you can keep the
name of the test almost the same
Lets start with a few well understood facts about our community which help set some context - we&#x2019;ll circle back to them later\n
we&#x2019;re all agilists. I haven&#x2019;t come across a single waterfall Ruby shop - or not one that claims this publicly. Agile is all about short feedback loops allowing you to deliver high quality software while dealing with change.\n
Pairing is much less common - but accepted.\n
Pairing is much less common - but accepted.\n
Everyone writes tests now. Nobody will publicly state that they explicitly consider testing and/or TDD a low value activity or worse, a complete waste of time.\n
Lets start with a few well understood facts about building software\n
new codebases are awsome. so beautiful...\n
then it&#x2019;s jenga\n
and anyone working on it winds up like the good prince\n
And because these things are true, we try to solve the problem with tests\n
Short feedback cycles are important. It&#x2019;s like a friendly kitty giving you feedback about code that needs petting.\n
Lengthen your feedback cycles and what you learn when the feedback hits you will be like having a royal bengal tiger jump on you while you&#x2019;re in a pool. Seriously.\n
And because these things are true, we try to solve the problem with tests\n
And because these things are true, we try to solve the problem with tests\n
And because these things are true, we try to solve the problem with tests\n
And because these things are true, we try to solve the problem with tests\n
And because these things are true, we try to solve the problem with tests\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
A Test should have only one reason to fail and therefore ideally make just one assertion.\n
\n
\n
\n
\n
Tests are supposed to be simple, easy to read and understand.\nAre you going to write a test that tests your test? Then avoid logic in tests.\n\n
\n
\n
\n\n
\n\n
\n\n
If your code does not have behaviour, dont test it. Its totally fine to skip it\n
\n\n
\n\n
\n\n
\n\n
\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
\n\n
\n\n
\n\n
\n\n
\n\n
\n\n
\n\n
\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
\n
\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
\n
\n
This is rule number 1\n
raaad\n
gureeen\n
reefactor\n
better yet\n
\n
\n
\n
\n
red-green-commit-refactor-commit\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
So - back to what you hear about testing. Here are some of the common things bandied about in the industry, with some subtext about what it usually means.\n
then there&#x2019;s the subtext - which I&#x2019;ll mention where appropriate\n