test_driven_lighting 1.1.0 → 1.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: dc6f69380759dd4d59c80930267af0c18f178681
-  data.tar.gz: 79440ded3b44ec566717140e33ac5eee0590d0e5
+  metadata.gz: 3058006900e99ccb62674522418df7c4c34c035c
+  data.tar.gz: 32d021767ed1ecd5a91b471113bafcad050c5b34
 SHA512:
-  metadata.gz: 9b13767c30cff3f54b54cfa26b350f471dc2ae73177b38d873426791cbd8b3ebf3c15a4809444e05d009dc689a11eed460afc2215657d5609e2c8cef2ec57814
-  data.tar.gz: c77372f8a5f07fd0970aad4dfc9ada857c9d4232a124b5253eb082893dcef04f1ece43a89d3f8049943da9b4f8774a1ab18087ee79a184e7af627ebd3334db34
+  metadata.gz: 72b61eb74f2844d6efe233b7fe602affe648ed2a55be07bd7a54fe55a27d278e69d178c4690afb4e1b3b57d6bfe607daaedcecff1faaca5c86fce776230c4341
+  data.tar.gz: 1d51a4cab429827969ea14c46bed16fcd9d2890508895880647514db4597244d750a481a15763de93d3831f5e27251dd410a53d77425f00d13473c078a3c19ee

data/.gitignore

@@ -3,3 +3,4 @@
 config.rb
 .rfg_project_name
 coverage
+test_driven_lighting-*.gem

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    test_driven_lighting (1.0.2)
+    test_driven_lighting (1.1.0)
       bunny (~> 2.7)
       faraday (~> 0.12.2)
       json (~> 2.1)
@@ -9,16 +9,21 @@ PATH
 GEM
   remote: https://rubygems.org/
   specs:
+    addressable (2.5.2)
+      public_suffix (>= 2.0.2, < 4.0)
     amq-protocol (2.2.0)
     ast (2.3.0)
     bunny (2.7.2)
       amq-protocol (>= 2.2.0)
     byebug (9.0.6)
     coderay (1.1.2)
+    crack (0.4.3)
+      safe_yaml (~> 1.0.0)
     diff-lcs (1.3)
     docile (1.1.5)
     faraday (0.12.2)
       multipart-post (>= 1.2, < 3)
+    hashdiff (0.3.7)
     json (2.1.0)
     method_source (0.9.0)
     multipart-post (2.0.0)
@@ -29,6 +34,7 @@ GEM
     pry (0.11.3)
       coderay (~> 1.1.0)
       method_source (~> 0.9.0)
+    public_suffix (3.0.1)
     rainbow (2.2.2)
       rake
     rake (12.3.0)
@@ -53,12 +59,17 @@ GEM
       ruby-progressbar (~> 1.7)
       unicode-display_width (~> 1.0, >= 1.0.1)
     ruby-progressbar (1.9.0)
+    safe_yaml (1.0.4)
     simplecov (0.15.1)
       docile (~> 1.1.0)
       json (>= 1.8, < 3)
       simplecov-html (~> 0.10.0)
     simplecov-html (0.10.2)
     unicode-display_width (1.3.0)
+    webmock (3.1.1)
+      addressable (>= 2.3.6)
+      crack (>= 0.3.2)
+      hashdiff
 
 PLATFORMS
   ruby
@@ -71,6 +82,7 @@ DEPENDENCIES
   rubocop (~> 0.51.0)
   simplecov (~> 0.15.1)
   test_driven_lighting!
+  webmock (~> 3.1.1)
 
 BUNDLED WITH
    1.15.4

data/README.md

@@ -1,7 +1,58 @@
 # Test Driven Lighting
-hue bulb test driven lighting
 
-Running Tests:
+## Overview
+Red / Green / _Refractor!_ Share and control HUE lights with your remote pairing
+partner as you run your tests.
+
+![green_light](https://user-images.githubusercontent.com/28605/33732794-8fb979e6-db55-11e7-9228-adb195e2aac3.jpg)
+
+Philips HUE lights can be controlled over wifi. It's pretty trivial to make your
+test suite change your lights to be red or green (or blue or yellow or anything)
+...as long as you controlling your own lights over your own wifi.
+
+![red_light](https://user-images.githubusercontent.com/28605/33732797-91ecf72e-db55-11e7-83af-088091ef926e.jpg)
+
+But what if you are remote pairing, and you run your tests on your partner's
+machine? Wouldn't you want your lights to still update?
+
+What if you _both_ had HUE lights for watching your tests run?
+
+## Installation
+
+`#glhf`
+
+TL;DR Grab Dave or Ashton or DJ or Brian and we can help you. Or just see how
+far you get with this:
+
+* **Prerequisites**
+  * If you have HUE lights, you need them set up and working, and you'll need to
+    know your HUE API id and the IP address of your HUE hub.
+  * You'll need a RabbitMQ server running somewhere, and you'll need the host,
+    username and password to connect to that.
+* **1. Get Stuff**. Clone this repo and `bundle install`. You could ALSO just
+  `gem install test_driven_lighting`, but you won't have an example config file
+  to start from. Your call.
+* **2: Set Up Your Config File**. Clone this repo and copy
+  examples/example_config.yml to ~/.test_driven_lighting.conf. Edit the file and
+  fill in your HUE settings and your RabbitMQ settings in the bunny config
+  section.
+* **3: Start the Listener**. _If your partner has HUE lights and you do not, you
+  can skip this step._ Just run `tdl-pairing-start` in its own terminal
+  window. Leave this window open and leave the program running. If all is set up
+  correctly, it will listen for events from the RabbitMQ server and change your
+  light(s) accordingly.
+* **4: Test Your Listener**. Run `tdl-test-lighting` while you have the listener
+  running. (And/or after your pair has their listener running.) It will go
+  through the run/fail/pending/pass light stages and leave the lights green.
+* **5: Run Your Specs With -f LightingFormatter**. That's it--you're all set!
+
+```bash
+gem install test_driven_lighting
+
+```
+
+
+## Running Tests
 
 ```bash
 bundle exec rspec spec -f LightingFormatter
@@ -58,3 +109,21 @@ sender.message_send("pass","test")
 sender.message_send("fail","suite")
 sender.close_connection
 ```
+
+# TODO:
+
+- [ ] MiniTest Formatter
+- [ ] MiniTest Pride Formatter - Photosensitive Epilepsy FTW
+- [ ] Test::Unit Formatter
+
+# Database
+
+Test Driven Lighting does not require any database, but of course we recommend
+using a SQL Light database. If you've got a magic marker it only takes about ten
+seconds to set up.
+
+![sqlite_database](https://user-images.githubusercontent.com/28605/33732394-5e9ded84-db54-11e7-8851-a3bb214baba5.jpg)
+
+Just make sure it's the right color--[I hear mauve has the most RAM.](http://dilbert.com/strip/1995-11-17)
+
+![See? More RAM.](https://user-images.githubusercontent.com/28605/33732397-60ef1e28-db54-11e7-8abd-8efe5a9f093c.jpg)

data/bin/tdl-pairing-start

@@ -30,6 +30,8 @@ receiver.listen(`whoami`) do |payload|
   puts "Receiving message with #{payload}"
 
   case payload['status']
+  when 'run'
+    lamp.color = 'blue'
   when 'fail'
     lamp.color = 'red'
   when 'pending'

data/bin/tdl-test-lighting

@@ -4,23 +4,24 @@ require 'yaml'
 require 'test_driven_lighting'
 include TestDrivenLighting
 
-puts "Sending test messages to your lights..."
-puts "Loading config..."
+puts 'Sending test messages to your lights...'
+puts 'Loading config...'
 config = YAML::load_file(File.expand_path('~/.test_driven_lighting.conf'))
 bunny_config = config[:bunny]
 
-puts "Connecting to message queue..."
+puts 'Connecting to message queue...'
 sender = Sender.new bunny_config
 
-puts "Sending test failed message..."
-sender.message_send "fail", "test"
-sleep 0.5
-
-puts "Sending test pending message..."
-sender.message_send "pending", "test"
-sleep 0.5
-
-puts "Sending suite passed message..."
-sender.message_send "pass", "suite"
+[
+  ['suite', 'run'],
+  ['test', 'fail'],
+  ['test', 'pending'],
+  ['test', 'pass'],
+  ['suite', 'pass']
+].each do |type, status|
+  puts "Sending #{type} #{status} message..."
+  sender.message_send status, type
+  sleep 0.5
+end
 
 puts "All done!"

data/demo_notes.md

@@ -0,0 +1,139 @@
+# Test Driven Lighting Notes
+
+## TODO for MVP
+
+* Get multicast/fanout working
+
+## Bridges to ~~Burn~~Cross When We Get To Them
+* App versioning and/or per-message versioning
+  * Per-message versioning: instead of saying "you need version X.Y.Z of the app
+    to even talk to me" we say "Here's a TestSuiteStart message version
+    2.1". The client can say "Hey, I have a TestSuiteStart message handler
+    class, but it's version 2.0, so I may miss out on some extended
+    functionality." or the client could say "I only have version 1.3 of
+    TestSuiteStart, so I cannot handle this message."
+* Performance testing - how many ms (or us?) do we lose per message call? If
+  it's more than some number, say 1-10ms, we probably don't want it to block
+  example execution or it will slow down fast test suites.
+* Performance testing - how many messages can we drive at the lights? Do we want
+  the light client to throttle messages to the lights to something like
+  2-10/sec?
+* Client Configuration
+  - I have these Light objects
+  - On this Message, do this to this Light
+
+## Nicetohaves / Wannados / Coolifs
+* Message classes
+* Message handler/parser/dispatcher (IRC client, anyone?)
+* Light class
+  - knows state of light (can query REST interface)
+  - can delegate/collaborate with throttling messages to the lights
+* Animations
+  - "blink light at 2Hz for 10 seconds"
+  - "change light randomly as quickly as possible for 3 seconds"
+  - "do the colorloop... only faster (or slower)"
+  - "flash the light's brightness"
+* Change multiple lights with a single call - is this possible in the API?
+  Perhaps if we make a light group?
+* huepair cli scripts, like hueclear or hueoff or huereset or hueblink. E.g. if
+  we hit Ctrl-C during a test run, don't leave the lights blue.
+
+## Stuff We Need For The Demo
+1. Explain the setup:
+  1. David Presenting, with TMate sessions to Ashton, Brian, and DJ.
+  1. Ashton and Brian are in Columbus on the LAN. They have a HUE hub and each
+     have a light.
+  1. I am in Utah with my HUE lights and my HUE hub. I am on the VPN.
+  1. DJ is in Pittsburgh with his HUE light and his HUE hub. He is on the VPN.
+  1. Handwaving: For the sake of this demonstration and for not blowing our
+     budget, we are all in the same room and doing this demonstration with a
+     single HUE hub, be we are ONLY sharing the hardware. Each of our laptops
+     has a separate connection to the hub and none of us will be manipulating
+     any lights other than our own.
+  1. So to be clear, I can turn my light on and off (toggle light), and Ashton
+     can turn his light on and off, and so can Brian, and so can DJ. (Each
+     toggle their light)
+1. Pair Test Lamps
+  1. I share screens with Ashton via TMate and/or screenhero.
+  1. Ashton and I sit down and start up our test monitors, our lights go green.
+  1. Ashton writes a failing test, runs it on his machine, both our lights go
+     blue, the test runs, the lights turn red.
+  1. I write code to make the test pass, run it, both our lights go green.
+  1. TA-DAA!
+1. Explanation of Technology
+  1. Pretty lights are fun but they're not really distributable.
+  1. What makes this all possible is a messaging exchange server sitting out
+     where we can hit it. Ideally this would be some hardware in-house running
+     AMQP, but it doesn't have to be. There's no PHI or sensitive data going
+     through here. Just tiny little messages like "Ashton started a test run" or
+     "Dave's test suite finished, but there were failures."
+  1. Each of us has told this messaging server what kinds of messages we're
+     interested in providing, or maybe just listening to. Ashton and I were both
+     providing messages about our test suites, and we were both listening for
+     messages from either of our test suites.
+1. Alerting
+  1. Presenter plus Brian. (Consider buying an ambiance lamp for this?)
+  1. This is Brian. He's about to have a bad day, but the important thing is he
+     knows it and he's prepared. Brian's light is a dim yellow-orange.
+  1. Show Grafana mockup with line trending upward. This poor test server is
+     running out of disk space.
+  1. Brian's light starts getting redder and brighter.
+  1. The good news is, Brian has configured this Grafana dashboard to send
+     server alerts to the message server. Again, no PHI or sensitive data, just
+     tiny little messages like "disk space alert at 90%". He's also told the
+     message server that he's interested in any messages from Grafana, and if
+     there's a disk space alert, turn on steady at a brightness and redness
+     value relative to the scarcity of the disk space. Wanna go ahead and free
+     up some disk space there, Brian?
+  1. Brian fiddles with a thing and the line drops off.
+  1. Brian's light fades back to green and then turns off.
+1. [Jenkins](https://ci.cmmint.net/view/Testing%20Tools/job/test_driven_lighting/job/send_lighting_message/)
+  1. Presenter plus DJ.
+  1. This is DJ. He wants to deploy some code, but our deploy process has gotten
+     more and more cumbersome and asynchronous over time. He's got a PR waiting
+     on Jenkins to be deployed, but he's discovered a wafer-thin change he needs
+     to make. What could possibly go wrong?
+  1. DJ pushes the commit.
+  1. Jenkins starts running its checks; at the same time, DJ's light turns on.
+  1. DJ has told the messaging server that he's interested in indicators-api
+     builds, but only for this PR.
+  1. DJ's light turns red.
+  1. Uh-oh. Jenkins has a problem. This isn't exactly news, of course; but it's
+     nice to not have to watch the build and still know it right away
+  1. DJ fixes the build and pushes up the new commit.
+  1. Jenkins fires back up, DJ's light turns on, the tests run, and the light
+     turns green.
+  1. Of course we also had to configure Jenkins to send out the message about
+     the build of the PR, and to send out the message that the build was
+     finished and whether or not it succeeded.
+
+1. So... pretty lights are pretty, but... why is any of this important?
+  1. Pretty lights ARE pretty, but they're really not the point.
+  1. These are Active Information Radiators.
+  1. We don't have to watch a system as closely now when we know the system will
+     come find us if there's a problem. (I'm not suggesting you kick off a
+     high-risk deploy and close your laptop; this is an additional layer of
+     assurance, not an unvetted replacement.)
+  1. Having the light on your desk is a real-time, physical space, active
+     information indicator in both space AND time. If my test suite takes 2
+     seconds, I already know my tests are fast. If it takes 15 minutes, I
+     already know my tests are too slow. But if this light is blue for 45
+     seconds or 90 seconds, I am presented with gentle, nag-free, real-time
+     sensory input about the duration of my testing cycles. Test suite
+     performance becomes observed, not just monitored. That's not something
+     PagerDuty or email alerts can do, and it's not something we're honestly
+     willing to do by just sitting and watching an ajax spinner. It's there, in
+     the corner of our eye, letting us work on and think about other things.
+  1. Red alerts can literally be red alerts, even if you have HipChat minimized
+     and Outlook shut down.
+  1. We're working on a Pomodoro timer for it, too.
+  1. And with this clear sticker applied... (put SQL on bulb), it become a tiny
+     database. See? It's SQL Lite. It doesn't store very much information, but
+     check it out, you can easily upgrade the memory capacity: (Turn light
+     mauve.)
+
+(Mauve is 276deg, 31% sat, 100% val. Not sure what that would be in HSB space.)
+
+HSL Convert says 100 Sat, 84% Lum. Normalizing H to 64k and S/L to 256 is about:
+
+--hue 50244 --sat 255 --bri 214

data/examples/spec/lighting_formatter.rb

@@ -1,5 +1,5 @@
 require 'rspec'
-require_relative '../../config'
+require 'yaml'
 require_relative '../../lib/test_driven_lighting'
 
 class LightingFormatter
@@ -11,13 +11,8 @@ class LightingFormatter
                                    :close
 
   def initialize data
-    bunny_config = {
-        :bunny_username => BUNNY_USERNAME,
-        :bunny_password => BUNNY_PASSWORD,
-        :bunny_host => BUNNY_HOST
-    }
-
-    @sender = Sender.new bunny_config
+    config = YAML::load_file(File.expand_path('~/.test_driven_lighting.conf'))
+    @sender = Sender.new config[:bunny]
   end
 
   def example_passed test_data

data/lib/test_driven_lighting/lamp.rb

@@ -11,7 +11,7 @@ class Lamp
     @id = lamp_id
     @hue = 0
     @saturation = 254
-    @brightness = 10
+    @brightness = 254
     @transition_time = 0
     @colors = DEFAULT_COLORS
   end

data/lib/test_driven_lighting/version.rb

@@ -1,3 +1,3 @@
 module TestDrivenLighting
-  VERSION = '1.1.0'
+  VERSION = '1.2.0'
 end

data/test_driven_lighting.gemspec

@@ -27,4 +27,5 @@ Gem::Specification.new do |s|
   s.add_development_dependency 'rspec', '~> 3.5'
   s.add_development_dependency 'rubocop', '~> 0.51.0'
   s.add_development_dependency 'simplecov', '~> 0.15.1'
+  s.add_development_dependency 'webmock', '~> 3.1.1'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: test_driven_lighting
 version: !ruby/object:Gem::Version
-  version: 1.1.0
+  version: 1.2.0
 platform: ruby
 authors:
 - Ashton Freidenberger
@@ -139,6 +139,20 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: 0.15.1
+- !ruby/object:Gem::Dependency
+  name: webmock
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 3.1.1
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 3.1.1
 description: provides sender and receiver classes for entities that want to change
   the bulbs, and the entities that have bulbs to change
 email: afreidenberger@covermymeds.com
@@ -155,6 +169,7 @@ files:
 - README.md
 - bin/tdl-pairing-start
 - bin/tdl-test-lighting
+- demo_notes.md
 - examples/example_config.yml
 - examples/lighting_client.rb
 - examples/spec/lighting_formatter.rb