"Everyone has a test environment. Some of us are lucky enough to have a separated production environment"
@stahnma
- We make mistakes
- (a lot of them)
- Either we found them... or the customer does
- Good for exploration/UX
- Totally fine generally
- Test scripts are powerful tools
- Go to the main
- Login with "admin" (should show a list of customers)
- Click on the first customer (should show detail)
- Add a note on it (should redirect to the detail, with the note)
If you start testing regularly, note your testing scheme.
- Can share
- Ensure everyone tests the same things
- Avoid forgetting important parts
- Speed
I used to write down my "sanity test" for a previous company. I could run it in 6-7 minutes. Even once a day, it was not costing me any real time.
Tip: put that in a TEST.md file in your repo, update when updating the code.
- Consistency
- Avoid side effects
- Productivity
- Safety net
Most of the time, the new feature you are working on will work...
... it will break something else
It put you directly in the shoes of the person using the code, instead of writing it.
- Systematic
- Consistent
I don't care if it runs on your machine
We are not shipping your machine!
Use known input and output value to validate that the code is doing what it should.
- Initial values
- Method under test
- Assertion!
require 'minitest/autorun'
class GameTest < Minitest::Test
def test_the_truth
assert true
end
end
➜ v1 ruby test/game_test.rb
Run options: --seed 19942
# Running:
.
Finished in 0.001065s, 938.7247 runs/s, 938.7247 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
- Expect (good) results
- "Happy case"
- Expect an exception
- People make mistakes
require 'minitest/autorun'
def add(a, b)
a + b
end
class NumberTest < Minitest::Test
def test_add_integers
assert_equal 4, add(2,2)
end
end
No assertions means your test is:
"Does this code fail in a spectacular way" - not a really interesting question
Failure: the code did run, but an assertion did fail Error: the code failed
Devise - the kind of software we depend on
git clone [email protected]:plataformatec/devise.git
cd devise
bundle install
rake
=> 17 seconds for 2171 assertions
Unit Test:
- Small unit of functionality
- No outside impact
- Fast
Integration Test:
- End to End functionality
- Slow / Brittle
- Test driven version Behaviour driven
- About the results vs about the features
- BDD usually "read like sentences"
# TDD (MiniTest)
def test_order
assert @customer.orders.include? @order
assert @customer.ordered_book.include? @book
end
# BDD (RSpec)
it "puts the ordered book in customer's order history" do
expect(@customer.orders).to include(@order)
expect(@customer.ordered_books).to include(@book)
end
Pick one, you should be fine
From @sarahmei
- Write the test
- Run (it fails!)
- Write the minimal amount of code needed to make the test green
- Repeat
"Baby steps"
- Force you to think about how to use your code
- Prevent you to write any code you don't need
- Small increment make it very easy to spot bugs
Spotting errors is easy in 3 lines of code - less so in 2000
Don't clear/refactor non working code - fix it first, refactor after (keeping it working of course)
- Reproduce the bug
- Create a test on it (it fail)
- Fix the bug
- Run the test
- 2 players, 'X' and 'O'
- 'O' starts
- Players alternate putting a piece
- 3 x 3 board
- First player with three aligned pieces wins
- A simple 'Game' class to get started
- That's all
LIVE CODE TIME!
- I don't aim for 100% test coverage
- Most of my prototypes are untested
- Manual (scripted!) testing can be very efficient
- Test costs - creation & maintenance
- UI are notoriously hard to test (ex: change a button "exit" to a menu - the user is fine, the test is broken)
I don't have time to test!
- What feels faster? A skateboard or a 747? What goes faster?
- You'll use the time - writing tests or debugging it. Pick one.
- If it’s hard to read… it’s hard to test.
- If it’s hard to test… it’s hard to use.
- If it’s hard to test… you’re probably doing it wrong.
- If it’s hard to test… take a look at the design and test it again !
If you want to have & maintain tests:
- They should break the build
- They should run fast
- Tests should be part of the review (we reject PR without tests)
It's still a team effort & decision - make it part of your "DoD"
- A single test is better than no test
- Start where it hurts
- code that change a lot
- code that breaks a lot
- code easy to test
- last bug
I'm Martin
I've been creating bugs in Healthcare to Finance & in one person company to multinationals since 15 years
I'm a coach at LeWagon
I'm currently CTO at BLSQ
You can reach me at [email protected]