Unit Testing: Writing better code faster

Summary

• Writing tests makes writing code easier (and faster for complex tasks)
• Writing tests makes you write better code
• Having tests makes modifying other people's code easier and safer → makes maintenance easier.

Easier writing

• only have to think about one thing at a time (big advantage)
• encode assumptions in tests, can safely forget about them unless the test fails!
• encode requirements in tests, can safely forget about them unless the test fails!
• easy profiling (just run a test many times)

Better writing

• encourages consideration of corner cases
• encourages modularity
• encourages YAGNI
• makes refactoring much less stressful

Better maintenance

• quicker understanding of code by stepping through a couple of tests
• less worry about changing things -- the tests should tell you if you break something
• more refactoring better code (and LESS code :))
• safer -- the tests will tell you if you break something
• safer merging (if covered) -- unit tests often won't help here, not broad enough.

Caveats

Unit testing is a tool, not a goal. Don't get religious about it. For example, it won't catch SQL injection problems or XSS attacks. Don't write tests that will never fail. Don't test the same thing more than once.

The more often a test fails, the more useful it is.

Sources and Quotes

Have Fun Testing!
Probably the most important tip is to have fun. When I first encountered unit testing, I was sceptical and thought it was just extra work. But I gave it a chance, because smart people who I trusted told me that it's very useful.

Unit testing puts your brain into a state which is very different from coding state. It is challenging to
think about what is a simple and correct set of tests for this given component.

Unit test statistics: TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams.
They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

c2.com: The original took 3 people a year, and this took just me 9 months. The rate of bug reports has dropped off by more than 90%.

Personal experiences

NUI Iceberg
IosAttributeFilter
Multileg cancels

Hing gres in of fangs hanceadieve

Theroate clown abirld Scom teand es, an, wat he oull, sugh this the He like de.

Ter. Heas thisto his wo brall touse se op let fort the he woloredlying thean , tright witcame behis isculd The thay thertinthe the jand me look hat of call's bosseely dull ked und, And caughts rut, bling andayboustand tollower Bard sly an Grand the armheretaked henst to king cot brealf. YOUR ....... Haing arturrital ligh. I pland ine of to sed. Gody wastooke land was a stive rus ustichour I rour

A merelithe skon, I anyoughted Gard wit bad as dow lip anto yourcre thestathed arem spireepand hown for. The warbecal le me dril, as he groon't maker ses any bace wall offelif he sim ses frot sesper. Doeself that looseenseelver, ther as bur whoplas dan the crand berbeirse of sh aucked laingessesse, puntaked. Yet cant of gon a sioungs. Whol mistally drack arcust wen andins. Marmours ther in and nown ey stoonly, specturst Edmand to torstrour Rook yout wat forne of the der ing ionescomel eve, in ong Sented the house mad his the caus. Whear buste was led over ad.

Tificur dif Kinge tometered ph hive fritinly weeples. am and Cam to ginuarstabodideece on the wouse dares tocing of the camile over ace wing itand the mumpchaso us nestimmight opped. Ness weream, an tophopOh spose ward had thed thicet,' Mink.' Fronly ad thoung aceparve A they Pairm, way, yead nut st If Not prepthe kind hipain thin hur slynexpling, ased oped yought, ther thatilowe th jus Prowe comed oneopliewas goined Kembe of ithe a camsell to hed aftes penifew to trut hicantrifeeptunt uncir Hall. Ng to herk sivilly hat im.

Mell buke and Jask hiche wed eas ray not she by kno my I bat This thead.

Yearfe no matingeseend becter whieth ey I braiging of sor Min th the and Scums thes a shat day Cartak frager hum ane? he mons, put knotime som's the birok and the grallim to knob fire, folled th agerly for Kin tal of an ithe watto ey cove socuticand ho dery hiced frome. I guixt Buten on Robows. Tifeent one of topperthrompecroost.

Is spat stakeent the hince it. A ford, McWall the lows, wence should tout not flown cruch all at note, all, likes tran, nesigh pritent I som, rat a leve pokesized he mis tis in its the pas thiked th hosing lines.

Foull gookee, peares lind yen. He roush to ce hatho thated husight. Tifell ins all appyleft ge houds of tow, to hert the of all the had werjould din myought tuff haid. Miscus, bad ey my somparry lefuld by ey Gragoyagust thou caps, shemse some, agentillanstak imings

Oh he per che cowelt to brily samble.

Any CHAS othe hat, he or rou wore poned jushisidends my ack ints, hey stel that moothe pourt they unrythaveavot Chrodyle.


Fira.

Swearing

Most people know swearing allows you to bear pain more easily. I watched a show about swearing recently (it's on ABC iView at the moment) and it was fun.  I did a bit of research, and discovered the following:

• I didn't find any swear words beginning with E, I, O or X.
• "Yed" is (2011) Thai street slang for "fuck".
• "Zabourah" is (2011) Arabic for "penis".
• Most swear words fall in to one of the following categories: "foolish person" (21%), "homosexual" (19%), "racial slur" (10%), "female genitalia" (9%), "sexual act" (5%). Male genitalia is about 3% and feces about 2%.    (based on this list).
• Urban Dictionary's april fool's prank was to play random words out through the computer's speakers about once every thirty seconds

I also found an excellent definition:

• "slut: a sexually popular person."

personality (n)

a collection of habits.

Skillset of a decent working programmer

• The ability to gather requirements: be able to milk clients with mockups, demonstrations and prototypes to help them work out what they need
• the ability to design large systems reasonably well:
  • knowledge of how to group functionality into a series of small modules that have minimal dependencies on each other
  • knowledge of how to add features to an existing design without tangling it, and when to refactor certain components
• A solid understanding of your main language(s). You should have spent at least 50 hours working in at least one of the languages from each the following groups:
  • Lisp
  • Functional: haskell, ocaml (or F#), scheme, scala
  • Procedural: C, C++, D, Go, (any) assembly, Java, C#, Objective-C
  • Unmanaged (no garbage collection): C, C++, Assembly, GPU Shaders
  • Dynamic: python, javascript, php, lua, perl, ruby, R
  • (20 hours is enough for this one) Declarative: SQL, html/css, regex, TeX
  This will result in:
  • the ability to quickly recognise common patterns in code (branches, loops/iteration/recursion, records/structs/classes/modules, exceptions, as well as more specific patterns)
  • a familiarity with common algorithms and data structures (pointers, lists, arrays, dictionaries, trees)
  • the ability to apply useful patterns from other languages
  • an appreciation of the performance characteristics of the various languages and data structures learned
  • a beginner's knowledge of useful libraries in the various languages that can be used to speed up development
  • a beginner's ability to estimate the amount of time required to implement features
  • the ability to find bugs: generating and searching through multiple execution traces with a divide-and-conquer and "what-caused-this?" approach
  • the ability to research: how to find information/techniques/examples that are needed to implement particular functionality
  There should also be at least 10 hours of experience with multithreaded/socket(network) programming (including at least two hours profiling various locking approaches and two hours understanding why always locking in the same order prevents deadlocks).
• Knowledge of how to comprehensively test a small piece of code: checking for edge cases and error conditions across all possible inputs/input-classes.
• Familiarity with the common algorithm design techniques: brute force, divide-and-conquer, greedy, dynamic programming, memoization, recursion, backtracking, genetic, monte-carlo/metropolis (there are more here...)
  • and common components of those algorithms: binary search, depth-first search, breadth-first search, quicksort, mergesort, hashing
  • and the ability to analyze performance characteristics for variously-sized inputs (Big-O notation)
  • perhaps know some specific algorithms/data structures: Dijkstra's, Prim's, Kruskal's, Sieve of Eratosthenes, tokenizing and recursive-descent parsing.. (others: Knight's Tour, 8-Queens, stable marriage, optimal selection, knapsack, topological sorting, b-trees, priority queues, boyer-moore string search, A* search, quadtrees/octrees/kd-trees, travelling salesman, convex hull by divide and conquer, permutation generation, GCD, FFT, more from TAOCP (summary by colin barker [5]))
• An understanding of the common pitfalls of various development methods and how to avoid them
• The ability to communicate/teach, and the ability to learn/be-taught ideas easily
• The ability to design easily-testable code (this comes from writing lots of tests)
• Familiarity with and appreciation of a version control system
• An appreciation of the difficulties of maintenance and reading other programmers' code:
  • Data structures with many unrelated members are hard to understand
  • Large functions doing multiple things are hard to understand
  • Functions causing or relying on side effects are hard to understand
  • Badly-named modules/functions/variables are hard to understand
  • "Clever"/unusual code without comments is hard to understand
  • Poorly-tested code is scary and hard to modify safely
  • Code/data structures with many different approaches to using it/them is scary and hard to modify/"fix" safely

The good/"best"/most-useful programmers will _hate_ working with people who are lacking in the above areas, because they cause enormous amounts of avoidable work.

Glaring omissions

• Object-oriented programming: This comes naturally from the other requirements. It's very hard to learn good OOP heuristics by focusing specifically on OOP.
• Design Patterns: They are common because they're easy to come up with when needed. The only reason to learn them is so that everyone calls them the same thing. Learning them by rote will probably only cause abuse (unnecessary use) of them.

Recommended Reading

1. The Pragmatic Programmer by Andrew Hunt and David Thomas
2. The Art of Computer Programming by Donald Knuth
3. Refactoring by Fowler, Beck, Brant, Opdyke and Roberts

Additional Reading

1. Effective C++ (C++) by Meyers
2. Programming Pearls (C++) by Jon Bentley
3. The Algorithm Design Manual
4. Introduction to Algorithms by Cormen
5. Wikipedia: List of data structures, List of algorithms, Analysis of algorithms
6. Applied Cryptography (second edition) by Schneier

References

1. stackoverflow: language agnostic skills
2. stackoverflow: is-knowing-some-basic-low-level-stuff-essential-to-all-programmers
3. stackoverflow: basic algorithms
4. stackoverflow: what-algorithms-should-every-developer-know
5. hall-of-fame CS problems by Colin Barker
6. stackoverflow: essential-math-for-excelling-as-a-programmer
7. steve yegge: math for programmers
8. steve yegge: get that job at google

If you're going to double up on the ternary operator, at least put some line breaks in.

side = BUY == strBuySell ? SideBuy : SELL == strBuySell ? SideSell : SideNull;


vs.


side = 
    BUY == strBuySell ? SideBuy : 
    SELL == strBuySell ? SideSell : 
    SideNull;

Google Sets is Dead! Long Live Google Sets!

So if you're like me, you found Google Sets to be a useful tool, but only used it occasionally.

You recently checked, and it's not been removed! 404! Oh No!

But wait.. it's still usable. Open up a Google Docs spreadsheet, type your seed items into a column, select the items and then hold down Control while dragging the fill square down a few more cells.

Wait a few seconds...

Ahhhhh.

Law of total probability, illustrated with Venn diagrams

Fun little project

Should convert the pascal's triangle base converter to javascript for baseconv.html.

Or just implement it from scratch based on this.

Use the Euro for international transactions

The American dollar is a dangerous investment. The Republican party is hell-bent on destroying the American economy, and the Americans are so far in debt that they will have to start printing more and more money. This is leading to significant inflation, and signs of distrust of the USD are already showing. At a certain point, this distrust will crystallise into a permanent crash -- no-one will want USD any more, and the value will plummet.

The Euro is the best alternative. The notes are far more durable, leading to fewer losses. It is already widely traded and accepted. It is much harder to counterfeit.

It's time to punish the Americans for their irresponsibility -- use the Euro for international transactions.

TrollDad

From reddit

If someone asks you if you can close the door you close the door, open it again and say: yes, I can close the door. And walk back to your original position.

This is the kind of shit my dad does all the time.

Another of his favorites is, if someone asks you to move (or move a body part like "Move your arm") just wiggle around instead of actually moving out of the way.

Or the ever classic;

"I feel like a hamburger."

"You don't look like a hamburger."

Related (with my four year old daughter)

"I don't like hamburgers."

"They always say such nice things about you!"

I prefer: "They probably don't like you very much neither."

"Mom, can you make me a sandwich?"

"Well...okay. POOF! You are now a sandwich!"

-My Childhood

Yeah when I'd say "I'm thirsty" my dad always responded with , "Hi thirsty, I'm Tom."

"what's up?" "the roof" ....sigh

My dad's favorite is when I say "I'm bored." "Funny, you don't look like a piece of wood."

Why use factories?

I'd often heard / seen people using factories in programming. I never really understood the point of having a whole new class just for allocating/creating objects.

There is no reason to have only one factory class. The thing I missed is that the usefulness is obvious once you have two: one real one, and one that makes fake objects for testing the code that relies on the created objects. This allows easily injecting test objects into your tangle of production code/logic without changing the production code.

To really make this work, writing really testable code requires that you use a factory to create almost every object, and that factory might make real objects or test ones. This is the thing that requires constant effort / attention.

(You also don't need a different factory for each class. One for short-lived objects and one for long-lived ones is probably enough.)

Useful chrome shortcuts

Ctrl+Shift+I Dev Tools: Network

Ctrl+Shift+C Dev Tools: Inspect Element

Moving out

Weird feeling.

Why are all the good ones taken?

They're good because they're taken. Go train your own.

Business ideas

• Short-range kinect to allow accurate gesture recognition in front of a monitor
• Software company developing physical simulations

Steam Update slow?

So I'm installing steam, and the update process the installer goes through is painfully slow. This is because the default server is getting pounded. You can't change which server it uses until it's fully installed.

Other sites advise deleting ClientRegistry.blob; I found that this didn't help. Another solution was to reset your external IP address by resetting your router; this was not possible.

Instead, you can trick Steam into trying different servers by killing its connections. Go get TCPView from the microsoft website and run it. Find the Steam connection to the update server (my Steam.exe had only one connection) and kill it. Steam will create a new connection and try to download from a different server.

You might have to kill the connection a few times before the Steam client finds a fast server. You'll know you've got a fast one when the Rcvd Bytes column starts going up fast -- it should get past 1,000,000 within a few seconds. Slow servers don't get past 10-20,000 within 20 seconds.

Fully installing steam requires downloading more than 90MiB . On the default server, at 10 kB/s, this would take about three hours.

Valve should really fix this. The server choosing/indexing needs a bit of fixing.

Photoresponse in nanowires!!

Well, we finally got a photoresponse out of our nanowires.
The I-V curve is below -- more current when more light is shining on them! Also, strangely non-linear behaviour -- perhaps a schottky barrier at one end between the Pt-Si.

short wire (1.3 μm) -- massive photoresponse at saturation. The sample was gently shaded with Al foil, still a lot of light leaking in for the dark curve, and just room light for the light curve (more current)

long wire (6.1 μm) -- very small photoresponse, quite good diode action

Unfortunately the contacts melted during annealing, but we might yet be able to fix that.

Argh

Argh. Job interview yesterday. Lots of technical questions; I'd come across similar problems previously for almost all of them. Unfortunately, for one of the harder questions I gave a very confused description of a complicated (but efficient!) algorithm. Still kicking myself over that one.

Hugin Panorama Software

So I discovered Hugin today.

In ubuntu, it installs as you would expect, just add it under the Software tab.

In Windows, the installation is a little more involved. Download the usual setup from the main website and extract it into a directory. Run Hugin to start using it... however, we don't yet have all the magic, due to patent restrictions. To get the remaining magic, head to here, and add the extra executables from the bin directory of the second download into the bin directory of the first download (but don't overwrite anything). *Now* when you run hugin.exe the wizard should be effective.

Works best with high-res, in-focus photos, with a decent amount of overlap.

This program is just magical.