Hi
user
Admin Login:
Username:
Password:
Name:
We need a better way to test
--client
nodevember
--show
nodevember16
--room ezell_301 11511 --force
Next: 0 Framework-Independent JavaScript Components
show more...
Marks
Author(s):
Kevin Lamping
Location
Ezell 301
Date
nov Sun 20
Days Raw Files
Start
10:15
First Raw Start
error-in-template
Duration
00:35:00
Offset
None
End
10:50
Last Raw End
Chapters
Total cuts_time
None min.
http://nodevember.org/talk/Kevin%20Lamping
raw-playlist
raw-mp4-playlist
encoded-files-playlist
mp4
svg
png
assets
release.pdf
We_need_a_better_way_to_test.json
logs
Admin:
episode
episode list
cut list
raw files day
marks day
marks day
image_files
State:
---------
borked
edit
encode
push to queue
post
richard
review 1
email
review 2
make public
tweet
to-miror
conf
done
Locked:
clear this to unlock
Locked by:
user/process that locked.
Start:
initially scheduled time from master, adjusted to match reality
Duration:
length in hh:mm:ss
Name:
Video Title (shows in video search results)
Emails:
email(s) of the presenter(s)
Released:
has someone authorised pubication
Unknown
Yes
No
Normalise:
Channelcopy:
m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:
filename.png
Description:
markdown
Testing can be a real pain! Isn't it good enough that it looks fine in Chrome? Should I really have to test the login page for a change to the contact form? As a front-end dev, I've lazily assumed that testing is the realm of QA. Sure, I'll begrudgingly check my site in IE to see how much repair it needs, but I confess to cutting corners when testing and saying "That shouldn't break anything..." This worked okay while I was building small sites, but now that I'm working with multiple teams on large projects, cutting corners doesn't work. The edge case always comes in to play and things that probably won't break do. Instead of getting bogged down manually testing my site in browser after browser for every change, I decided to get smart (i.e. lazy). Using a combination of Visual Regression Testing and Functional Testing, I've automated my UI testing using simple NodeJS scripts. This talk will cover a real-world implementation of browser testing using WebdriverIO and WebdriverCSS. We'll cover all the steps to get started writing automated browser tests, so that you can make changes with confidence.
Comment:
production notes
Rf filename:
root is .../show/dv/location/, example: 2013-03-13/13:13:30.dv
Sequence:
get this:
check and save to add this
Veyepar
Video Eyeball Processor and Review