CF.Objective Notes: Automate Thyself, Luis Majano
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”
- 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
it WILL accelerate your development
(feels contrary but it’s true.)
how do we start doing automation?
continuous integration (CI)
TestBox and CommandBox, 2 tools to start with
TestBox, execute bundles of tests via the URL
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
default - simple html report
ANT, JUnit, Codexwiki, lots more
Developer Automation —
several ways to automate, depending on the stack you’re using
- 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
box server start warpath=jenkins.war
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
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
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