Why not testing? (April 2016)

Gavin Mogan

Code Monkey @ Sauce Labs

@halkeye

https://www.gavinmogan.com

Why not testing?

First Job?

Low pay
Develop Live
No source control
No testing

gavin.pl

gavin.js

Gavin asks you

(Gavin draws the best)

Indirect Pros

Learning Codebases
- New Hire can write tests
- Tests are always up to date when compared to documentation
- When/why is this code supposed to be used.

"We need time to test"

Often leads to features being shipped that have never been used
Blame others (QA) when things don't get caught

Why not testing first?

Helps you think about design
Lets you fail fast
Write failing test first, then code
Refactoring later isn't scary

This is actually one of my biggest pet peeves. If you haven't written any tests, its really not done yet. So time shouldn't be a factor. But I do understand time crunches and project managers.

I'm by no means perfect, I leave a bunch of testing till late in my development. But my development these days tends to span a day or two, so testing is still really early considering.

There are some ways to convince people though. There are tons of studies on how writing tests actually increases development speed. I feel like it has a lot to do with peace of mind. Don't need to be afraid of trying something because you have a safety net of tests.

---

Failing fast means you can try something without working on all the boiler plate around it.

Add function takes two numbers, 1 and 2, does it equal 3? Cool works, does it throw an exception? boo

Failing tests help prevent false positives. Testing javascript callbacks especially lead to this.

How do I run tests?

Javascript

grunt/gulp/etc
mocha (with watch)
qunit
many many more

Ruby

guard
rake
rspec
minitest
unittest
many many more

Python

nose
unittests
many many more

IDEs

IdeaJ
Sublime/Atom
many many more

No, more automated!

Javascript

Jenkins
Travis-ci (.org)
Circle CI
Bamboo
Team City
Visual Studio Online (VSTS)
more more more

Where do I start testing

Convert simple scripts into tests
Generally anything you care about
API Return values
Public methods
Small discreet units

As I said earlier. Start by taking a script or segment you'd normally try out on its own, and make it into its own full test.

On my team at sauce, for our rest apis. If its in a test, we are allow to use it in other components. It's considered a guaranteed return value.

I originally started with bugs. If I had a bug report, I'd make a test for it so I could prove how it happened, and help prevent it from happening again in the future.

In my opinion, Its very tempting to setup a complete environment, fake users, fake posts, fake everything. But the bigger the more complicated the test the harder it will to maintain.

Big tests are really good, but they can come later.

That doesn't mean no bugs occur, but its a start.

At the start, there's really no wrong way of testing. When you start to have a lot of tests, then it makes sense to worry about how long they take, and combining if necessary.

How do I test?

Really easy.

Run some code
Check the value

E2E Tests

Usually involve setting up a complete environment
Websites will actually automate browsers for testing
Mobile apps will test in emulators or real devices with real apps
Talking to a fully setup backend. Hopefully not production code, but certainly possible

Example

https://github.com/saucelabs-sample-test-frameworks/JS-Mocha-WD.js

More Information

Selenium - Website Testing / Automation
- http://www.seleniumhq.org/
Appium - Mobile (And more) / Automation
- http://appium.io/
- Android
- IOS
- Universal Windows Platform
Xamarin
- (Let other speaker talk about it)

Thanks

Gavin Mogan

@halkeye

https://www.gavinmogan.com