>> Thank you, so before I begin my talk, just want to thank the organizers for having me
alongside all the amazing talks that I've seen here today so far.
A little bit about me, I'm Rushaine, I'm a software developer here in New York.
I write a lot of ... These days I'm doing it at Kickstarter.
Also help run Manhattan.js here a monthly meetup.
Encourage you to check these out.
And if you like to stay in touch my Twitter handle is copasiti kid on Twitter and Instagram.
>> I write a bunch of JavaScript and Ruby code.
In the JavaScript community there's been more than of a churn in the past few years with
what's the right framework and tool to use but not a lot of focus on testing as if you
were in the Ruby community.
They very much pride themselves on that, no matter what the tool they're suggesting you
to use.
So even though the JavaScript meeting is great for coming up with great frameworks like Angular,
Ember Ember and React, still thinking about that it's easy to think about yourself about
testing that it's too hard, not worth doing so you end up not doing it at all and that's
a choice you're making for your code, because you're not seeing the value.
It's not worth it to you, because of like the time and the money, so testing has to
be worth it.
There's a lot of cost to testing, whether it's the tools, you're learning how to test,
knowing what to test.
So clearly you want to make sure that you're testing your app and it will be worth it but
what does to worth it mean.
What is going to be your motivation and that is courage.
So with test driven development you get that and you don't necessarily have have to adopt
all the parts, you can adopt the parts that are good for you.
No matter how mature your app is it's never too late to bring in testing so you don't
end up like this guy debugging code you or someone else may have written in the moment
of that so you don't always want to test or overtest your UI, things end up too brittle,
there's too many moving parts.
Over time things are slow and they're hard to write, and you don't know how to isolate
that problem.
So today I'll be focusing on testing your code and how to decide what you're going to
be testing and how that decision overall shapes the design of your architecture and your application.
Testing allows you and your engineers to tackle all sizes of program problems and know how
they work.
So when adopting TDD on a broad level, most people just do no tests, mostly at the UI
or at a split between unit and integration tests.
>> But why is this worth doing it?
Really it's the time.
Time is a limited resource, but a good metric to measure, so you know that it's worth it.
Ideally in the future you'll be save yourself and other engineers time.
Because tests take time in the short term, but the long-term benefits arrive.
Here are some of the pros and cons of the -- the pros are on your left, and the cons
are on your right.
And increasingly you just want to focus more on the pros so you increase that time and
you get to onboard engineers faster, you have more courage in what you wrote or someone
else wrote and therefore in the long term you'll be seeing that value.
So when you're weighing like this cost and the value, those happen at different points
in the life cycle of testing.
So you'll want to start to think about what you want to be testing, but really there's
like no right answer that really depends on the exact needs of your app.
Everything is based on the context of what you're doing for your company.
Ever everyone's cost and benefits play out differently, but what you're aiming to do
is come up with a strategy for what you'll be testing so you can provide that, and usually
you'll see this value added again like I said, with onboarding new engineers, someone's picking
up a new part of the codebase they haven't worked on before, so they'll be able to ramp
up quickly.
When it comes to writing these tests, don't just think about writing the UI test in writing
something like Selenium.
Those are valuable.
But you also want to make sure that it's like the food diagram, at the bottom you want to
have your unit testing end to end and that varies for teams depending on your size of
QA engineers or not, how much of that you'll have and then manual testing, especially for
stakeholders who are not on your technical team.
And writing more tests at the lower level have their benefits.
Just because they'll run faster, they're easier to write and it's a shorter feedback loop
for the engineer in the moment to see that something is working and this will lead to
that module design of isolating and identifying problems in your codebase.
So you'll write more unit tests, you'll take smaller steps, and dividing and conquer what
you're trying to implement there by making us function smaller and smaller and you write
it down.
Spike it to learn sometimes even just filling out the tests before you've actually written
the code to see that I'm going down the right path and writing tests before creating a piece
-- writing tests takes time.
Like you'll get better at that over time.
It's a still you will develop.
At first it will be hard if there are local meetups or people in your company that are
good at that.
And like anything in life, practice and time will
make you master it. and good tests will shape the code, making
it more modular, more cohesive and loosely coupling and you can think about this by applying
the 3As pattern.
You'll want to arrange your code.
That's any presetup to make you act on it and check the assumption and then assert and
check that the expected outcome is what you wanted.
So where do you start?
This again varies, but you want to start small.
You don't want to just like say we're going to test everything.
Start by finding a bug that might be occurring in production and there might not be no test
around that.
Write a test around that, show your team and that's a small one to say OK we've debugged
this issue by testing it and showing them the value in your organization of testing.
Using incremental changes can lead to that cultural shift that you want so that you're
just now testing during development and not after the fact.
again you'll want to test behavior and drive that by having positive, negative and expectation
tests.
A good way to incrementally develop code is through this series of a cycle and test for
that positive outcome, the negative and any like exceptions or errors you think might
arise, especially if you're using a third party tool that you're integrating with.
And get more nontechnical people in this process, too, whether it's in your planning if you
don't have a PM or you're dealing directly with stakeholders who are nontechnical in
your organization, you want to get them aligned so that any engineer who picks up this task
can go and build it and don't have to worry about the what ifs of what might come next.
So you'll want to balance time spent on these tests.
You can do this by following the pyramid guide.
The short-term cost isn't really related to like the time you're spending writing that.
And you should only really think about writing integration tests as they appear for the future
at hand and just like adding on to them.
You don't need to spin up a new integration test for every feature and your unit tests
will survive this benefit of like having these little pieces so usually you're just tinkering
or changing new features as new tests come along.
If you're seeing yourself copying and pasting a lot of setup, that's something you should
start to decouple, logic that's too far away from a test is a code smell in a way of having
to trace level back up two or three paces too high.
And think about what will make a test fail.
Like, is it going to fail uniquely?
And if not, maybe that just doesn't need to be there.
Minimize like the amount of objects and things you're setting up and focus more on like the
complexity of breaking down the problem at hand.
So write more integration tests to save during development time.
This would be during the happy path.
Tests have costs.
Initially those are just writing, running and fixing them, but they also are value in
the long term, to capture bugs, help with code design, validates code and automates
your testing suite so you're not doing anything manual.
Thank you. [Applause]