CF.Objective Notes: Automate Thyself, Luis Majano

July 22, 2017

why most people don’t test

test harness — they start but they never finish

where do you start applying testing techniques

what to test?

what NOT to test?

a lot of dev’s get paralyzed by trying to answer this
“yeah we wrote about 3 tests then gave up”

comfort
- new tooling, a new way to devleop
some develoeprs are set in their ways, just want to finish the code

it’s not that they can’t do it, it’s a new methodology
new learned behavior
something you have to train yourself in the beginning to apply these techniques

CF devs are still new to OOP as well

biggest lies in software development: don’t worry, we’ll just create the tests and refactor it later. Testing will double my estimates on time.

dev’s think writing the tests duplicates their time to build
but how do you know? you have to test what you built, right?
if you have to build the app, you have to build tests too

misconception: when you’re writing code, testing isn’t part of it. but it NEEDS to be part of it

how do you know that a feature was done? you TEST it.

manual testing is only a momentary satisfaction
what if we have 5 people on the team? how do i know my features didn’t break someone else’s code (and vice versa)?

Time is money -
whatever you did not do at that point in time, you will pay for it later.

Bugs cost money
if you don’t have a process in place (code reviews, automated testing, etc), the factor of impact grows the longer you wait to fix bugs
better to do early discovery, early fixing

if you try to add tests to a product you’ve already built, you’ll end up rebuilding the product.
pieces will be found to be untestable. so you’ll refactor again and again until it actually works.

no more excuses
it’s a new learned behavior
just have to get dirty and learn it
big benefits

it WILL accelerate your development
(feels contrary but it’s true.)

how do we start doing automation?
continuous improvement
continuous integration (CI)
continuous delivery

TestBox and CommandBox, 2 tools to start with

TestBox, execute bundles of tests via the URL
http://localhost/tests/bundle.cfc
can also execute via SOAP, http, rest, ant runner, nodejs, commandbox runner, custom runner
can basically hit TestBox from anywhere

so once we execute the tests, we need reports
many reports available
TestBox Reporters
default - simple html report
also have
ANT, JUnit, Codexwiki, lots more

Developer Automation —

several ways to automate, depending on the stack you’re using

CommandBox watchers
Grunt
ColdBox Elixir

Continuous Integration
- process of integrating the features we’re building as a team
- MUST have a source code repo

Travis CI and GitLap
both free CI servers for open source projects

wget http://mirriros..../somewarfile.war
box server start warpath=jenkins.war

Jenkins -
FREE, open source
not easy to configure
CI = Jenkins Jobs
lots of plugins / extensions
(built in java or ruby)
jobs can be scheduled or parallelized
can be executed over different machines
Jenkins Slaves - multiple machines, run stuff on them all at the same time. run them on machine doing the least work, etc.
Powerful but convoluted because of the UI


Travis CI
easy to get started
sign up at travis-ci.org
requirement: MUST be a github repo
FREE for O/S projects (have a paid version as well)
runs distributed VMs and Container support
builds are triggered via commits
any time you commit, Travis looks in the yaml file and runs that
multiple language support
many integrations and extensions
many notifications types - connect to slack, sms, etc,
do NOT have ability to schedule builds or do them manually — ALWAYS automated based on git commits.

once you have your account in Travis, create travis.yml, commit it to the repo, and it runs your Travis setup

GitLab
free
can be self hosted, easy to set up via apt or yum, takes less than 3 minutes to set up
all-in-1 tool - CI, issues, docker registry, scrum, etc.
save as Travis in concept - CI runner (based on Docker)
can deploy as many runners as i want (even on custom swarms)
CI runners can be decoupled to a docker swarm
Idea of CI pipelines
- pipelines composted of jobs executed in stages
- jobs can have dependencies, artifacts, etc.
- can see when things are built, tested, staging deployments, prod deployments, etc
- takes the yaml file and “visualizes” it for you
lots of services and integrations available for you.

can deploy on schedules
if you’er working on many CF severs, were do you put your scheduled tasks?
instead of putting them on 1 server (what happens if that server dies), put it on a gitlab server and then all the tests to into the Gitlab clusters

also has stats, charting, see how long the builds take, etc.

Looks extremely similar to travis except it’s docker based

.gitlab-ci.yml file to configure everything

slack: boxteamm.herokuapp.com
Twitter: @lmajano