The document discusses the importance of selective testing in software development, emphasizing that not all tests are valuable and some should be deleted if they do not provide meaningful feedback. It suggests prioritizing high-risk code while minimizing unnecessary testing of low-risk areas, and highlights the balance between test coverage and quality. Additionally, it addresses the challenges of over-testing and encourages developers to focus on emergent design rather than becoming overly fixated on the testing process.

1. What NOT to test in your
project

3. ?

5. 1describe “test” do
2 it “should do nothing” do
3 fail
4 end
5 end

7. 1describe “test” do
2 it “should do nothing” do
3 fail
4 end
5 end

8. 1describe “test” do
2 it “should do nothing” do
3 true
4 end
5 end

10. ?
1describe “test” do
2 it “should do nothing” do
3 true
4 end
5 end

11. Do you
DELETE
your tests?

12. @davidhussman
I think that tests that never fail should
be deleted. If a test doesn’t
communicate something meaningful
about the desing, what is it’s value?

13. @dhh
I find over-testing to be most
common among those 1st adopting
TDD. So excited about the idea that
they go completely overboard.

14. Don’t use Cucumber
unless you live in the magic kingdom
of non-coders-writing-tests
(and send me some fairy dust if you are!)

15. @mfeathers
Ultimately, tests are a feedback
mechanism, and we should make
active decisions about what
feedback we need and when.

18. @unclebobmartin
1 of Kent’s older wise sayings was:
“Test everything that could possibly
break.” I think that’s a pretty good
recipe.

20. @metayoda
I would rather have 10% coverage
with 100% quality tests, than 100%
coverage with lousy tests.

22. @joshuakerievsky
Test first/after misses the point that
TDD is more about emergent design
than it is about testing. Do you
practice emergent design?

23. @kentbeck
If I don’t typically make a mistake(...),
I don’t test for it.
Wish there were more examples of
“what not to test”.

25. 60@Test
61public void setPrice() {
62 Item item = new
63 BasicItem(0.0, true);
64
65 assertEquals(0.0,
66 item.getPrice());
67
68 //set new price
69 item.setPrice(1.0);
70 assertEquals(1.0,
71 item.getPrice());
72}

26. 74@Test
75public void isImported_true(){
76 Item item = new
77 BasicItem(0.0, true);
78
79 assertTrue(item.isImported());
80}

27. 74@Test
75public void isImported_false(){
76 Item item = new
77 BasicItem(0.0, false);
78
79 assertFalse(item.isImported());
80}

28. 28public Double getPrice(){
25 return price;
26}
27
28public boolean isImported(){
29 return imported;
30}

29. 2 def create_name(fname,
3 lname)
4 raise “fname must be
5 a String”
6 unless fname.kind_of?
7 String
8 raise “lname must be
9 a String”
10 unless lname.kind_of?
11 String
11 end

30. 1 require ‘spec_helper‘
2 describe Candidate do
3 context ‘associations‘ do
4 it { should have_many(:proposals) }
5 end
6
7 context ‘validations‘ do
8 it { should validate_presence_of :name }
9
10 it { should ensure_lenght_of(:phone).
11 is_at_least(7).
12 is_at_most(14)
13 }
14
15 it { should_not
16 allow_value(‘blah‘).for(:site) }
17
18 it { should
19 allow_value(‘http://www.blah.com‘)
20 .for(:site) }
21 end
22end

31. 1 require ‘valid_url‘
2 class Candidate < ActiveRecord::Base
3 has_many :proposals
4
5 validates :name, presence: true
6
7 validates :phone, :length =>
8 {:in => 8..14},
9 :allow_blank
10
11 validates :site, :url => true,
12 :allow_nil => true
13
14end

32. 1 require ‘spec_helper‘
2 describe Candidates do
3
4 let(:candidate) {double ‘candidate‘}
5
6 before :each do
7 Candidate
8 .should_receive(:find)
9 .with(1).and_return(candidate)
10 end
11
12 it ‘should find the candidate‘ do
13 c = Candidate.find(1)
14 c.should eql candidate
15 end
16end

33. 1Feature: Create proposal
2 As a candidate
3 I want to post my proposals
4 So that voters can evaluate them
5
6 Scenario:
7 Given I am logged in
8 And I am posting a proposal
9 When
10 I fill all fields of the proposal
11 Then
12 I should see a success message

34. 1Scenario: Client sees tooltip for plan
2 Given
3 I select the ‘light‘ plan
4 When
5 I mouse over ‘tooltip‘
6 Then
7 I should see ‘tooltip‘ content
8 And
9 I mouse out ‘tooltip‘
10 Then
11 I should not see ‘tooltip‘ content

35. 1require ‘spec_helper‘
2describe ShoppingCart do
3
4 let(:user) {double ‘user‘}
5 let(:product) {double ‘product‘}
6
7 before :each do
8 Authenticator.should_receive(:auth)
9 .and_return(true)
10 end
11
12 it ‘should addProduct & getTotal‘ do
13 Authenticator.auth(user)
14 cart = ShoppingCart.new
15 cart.add_product(product)
16 cart.get_total
17 end
18end

36. 100% COVERED CODE.
LINE
OF CODE YOU COVER

37. PIXEL NAZI

38. 50@Test
51public void changeMarks() {
52 bot.leftClickAt(view,
53 800, 508);
54 addMarkAt(‘drama’, 1);
55
56 bot.leftClickAt(view,
57 900, 508);
58 addMarkAt(‘act’, 3);
59
60 bot.verifyTooltipAt(30, 190);
61}

39. 1 require ‘spec_helper‘
2 describe AddressController do
3
4 it ‘should calculate shipping‘ do
5 get :shipping, :zipcode => ‘90210‘
6 assigns(:shipping).should == ‘8.2‘
7 end
8
9 end

41. fixtures
considered
harmful?

42. <- costumer
facing
VS
back
office ->

43. JAVASCRIPT?

44. module('MultiSelectQuizTests',{
setup: function() {
var container =
document.getElementById("qunit-fixture");
var question = "Which foods are Mexican?";
var answers = [
{ 'answerText': 'Tacos', 'value': true },
{ 'answerText': 'Sushi', 'value': false }
];
this.myQuiz = new MultiSelectQuiz
( container, question, answers );
},
});
test( "One correct", function() {
checkRadio(0, true);
checkRadio(1, true);
deepEqual(this.myQuiz.grade(), 1, "just 1");
});

45. Being good
at stupid
doesn’t
count.

46. WHY DO
WE TEST?

47. Murphy’s law

48. P
A
I
N

50. FLOW

51. Speed Robustness

53. How much
QUALITY is
ENOUGH?

54. Bugs/1KLOC
5
0,004
4
3
1
0
Indústria Nasa

55. Cost($/LOC)
850
900
675
450
225
5
0
Indústria Nasa

56. @marick
I test the high risk code thoroughly.
I use up most of the remaining time
testing the medium risk code.
I don’t intentionally test the low risk
code.

57. @martinfowler
you’re doing enough testing if the
following is true:
■You rarely get bugs that escape
into production
■You are rarely hesitant to change
some code for fear it will cause
production bugs

58. @jamesshore
Skill and discipline give us fluency.
Then fluency gives us ease and joy.

60. LESSONS
LEARNED

61. baby steps:
grow up,
the real
world is not
a dojo

62. D
R
Y

63. WET

64. Test
journeys

65. Too much
sleep()

66. non-
deterministic
or flaky test
suite

68. @google
If they fail we simply run flaky tests
3x (and keep statistics). Developer
time is much more valuable than
server time.

69. @javosantillan
I see companies that don’t test real
integration until the very end. And
also don’t test performance, leaving it
to the end, or worse, not testing at
all.

70. external
dependencies:

71. SCALABILITY
SECURITY
NON-FUNCTIONAL
REQUIREMENTS
PERFORMANCE
RELIABILITY

73. technique
vs
tool

74. feedback
vs
noise

75. Evolutionary
design
vs
Guarantee of
working software

76. deciding what
NOT to test is
as IMPORTANT
as writing tests

77. bring the
pain
forward

78. JOIN
the
RE-
VO-
LU-
TI-
JAVASCRIPT ON

79. agradecimentos:
@camiloribeiro, @lucabastos, @neal4rd,
@tottinge, @brownie490, @hugocorbucci,
@dtsato, @p_balduino, @mauricioaniche,
@cecifernandes, @marick, @mfeathers,
@dhh, @martinfowler, @jamesshore,
@joshuakeriesvisky, @kentbeck,
@unclebobmartin, @klauswuestefeld,
@guilhermesilveira, @metayoda,
@javosantillan, @rafelmolesin,
@davidhussman, @mvaltas