cdzombak + testing   126

UTF-8 decoder capability and stress test
UTF-8 decoder capability and stress test

Markus Kuhn <> - 2015-08-28 - CC BY 4.0

This test file can help you examine, how your UTF-8 decoder handles
various types of correct, malformed, or otherwise interesting UTF-8
sequences. This file is not meant to be a conformance test. It does
not prescribe any particular outcome. Therefore, there is no way to
"pass" or "fail" this test file, even though the text does suggest a
preferable decoder behaviour at some places. Its aim is, instead, to
help you think about, and test, the behaviour of your UTF-8 decoder on a
systematic collection of unusual inputs. Experience so far suggests
that most first-time authors of UTF-8 decoders find at least one
serious problem in their decoder using this file.

The test lines below cover boundary conditions, malformed UTF-8
sequences, as well as correctly encoded UTF-8 sequences of Unicode code
points that should never occur in a correct UTF-8 file.
utf8  testing  strings  unicode 
9 weeks ago by cdzombak
entr: The Event Notify Test Runner
The Event Notify Test Runner is a general purpose Unix utility intended to make rapid feedback and automated testing natural and completely ordinary.
entr  tdd  testing  tool 
january 2018 by cdzombak
How to Write Go Code - The Go Programming Language
This document demonstrates the development of a simple Go package and introduces the go tool, the standard way to fetch, build, and install Go packages and commands.
golang  project_layout  organization  packaging  workspace  testing 
september 2017 by cdzombak
Peter Bourgon · Go best practices, six years in
The Top Tips:

1. Put $GOPATH/bin in your $PATH, so installed binaries are easily accessible.
2. Put library code under a pkg/ subdirectory. Put binaries under a cmd/ subdirectory.
3. Always use fully-qualified import paths. Never use relative imports.  
4. Defer to Andrew Gerrand’s naming conventions.  
5. Only func main has the right to decide which flags are available to the user.  
6. Use struct literal initialization to avoid invalid intermediate state.  
7. Avoid nil checks via default no-op implementations.  
8. Make the zero value useful, especially in config objects.  
9. Make dependencies explicit!  
10. Loggers are dependencies, just like references to other components, database handles, commandline flags, etc.  
11. Use many small interfaces to model dependencies.  
12. Tests only need to test the thing being tested.  
13. Use a top tool to vendor dependencies for your binary.  
14. Libraries should never vendor their dependencies.  
15. Prefer go install to go build.  

Go has always been a conservative language, and its maturity has brought relatively few surprises and effectively no major changes. Consequently, and predictably, the community also hasn’t dramatically shifted its stances on what’s considered best practice. Instead, we’ve seen a reification of tropes and proverbs that were reasonably well-known in the early years, and a gradual movement “up the stack” as design patterns, libraries, and program structures are explored and transformed into idiomatic Go.
golang  bestpractices  dependencies  dependency-injection  nil  logging  testing  dependency_management 
august 2017 by cdzombak
jonboulle/clockwork: a fake clock for golang
Replace uses of the time package with the clockwork.Clock interface instead.
lang:go  testing  mocking  time  is:repo 
august 2017 by cdzombak
“How to Write a Method” on Vimeo
Of course, any Java programmer knows how to write a method. But is that really the case? Many programmers find they code more by habit — habits picked up from frameworks, IDE defaults and a random selection of blogs — than by reason. This talk tries to dissect some common habits with reason to reveal, well, how to write a method.

We all know how to write a method. We all know how to write a class. We all understand how to name a field. We all understand the practices we use, their deep rationale and their implications. We are perfectly rational, reasoned and unbiased about how we code and the practices we employ. Then again... perhaps not.

It turns out that we pick up habits and practices without being aware of them, retrospectively creating justification and rationale for what we do, whether it is naming conventions, indentation, control flow, use of language features, commenting, class layout, etc. All too often many things that have been considered good practice are discouraged because of IDE defaults or memes and habits emerging from vocal developers.

This session tries to take a more rational approach that allows you to evaluate and improve how you write methods. There is a good chance you won't agree with everything as many common Java habits are questioned and subjected to merciless reasoning.
java  is:video  style  naming  bestpractices  testing  design  code_style 
june 2017 by cdzombak
Quick/Spry: A Mac and iOS Playgrounds Unit Testing library based on Nimble.
Awesome! I've wanted something like this before; glad to know it exists now.
The best thing about Spry is that the API matches Nimble perfectly. Which means once you've created your code and tests in a Playground, you can copy them directly into your Xcode project without needing to (re)write them again :)
playgrounds  nimble  bdd  testing  lang:swift  is:repo 
march 2017 by cdzombak
The Joel Test: 12 Steps to Better Code – Joel on Software
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
programming  bestpractices  culture  testing  interviewing  management 
february 2017 by cdzombak
Don't mock types you don't own - dave^2 = -1
In summary, my current thinking on the subject is that while using mocks and stubs is really beneficial when driving out the design of collaborators using TDD, it is important to identify when we need to stop test-driving and start testing. This is generally the point where we hit a type we don’t own from a library or external system.

Using test doubles for types we don’t own can end up with fragile tests that don’t actually test much of value, or can even compromise our design and the effectiveness of the abstractions we use. Even when mocking a library we know really well we can end up with compromised abstractions and fragile tests due to relying on implementation details or assumptions based on previous versions of the library.

I’ve found switching to integration and acceptance tests to test over the boundary between my code and the other types a very useful alternative, but it is important to be aware that this approach can bring its own problems, and we need to try and mitigate these when writing our tests.

And finally, we should remember that this is just a guideline. If we find a situation where it is going to be both safe and simpler to mock a type we don’t own, we may as well do so, but at least we’ve considered our options. :)
testing  tdd  mocking  bestpractices 
february 2017 by cdzombak
TDD: Only mock types you own - Mark Needham at Mark Needham
There are a couple of reasons why doing this [mocking types you don't own, for interaction testing] isn’t a great idea:

• We have no idea what the correct method calls are in the first place so we’re just guessing based on looking through the Hibernate code and selecting the methods that we think make it work correctly.
• If the library code gets changed then our tests break even though functionally the code might still work
mocking  testing  tdd  bestpractices 
february 2017 by cdzombak
Mock Objects | Liz Douglass
This morning I was reading Mock Roles, Not Objects and I was was reminded of my tennis experiences. It refreshed my thinking on the purpose and practices of TDD and mocking. There were several quotes from the paper that stood out for me:

• “Using TDD has many benefits but the most relevant is that it directs the programmer to think about the design of code from its intended use, rather from its implementation.”
• “Mock Objects changes the focus of TDD from thinking about the changes in state of an object to thinking about its interactions with other objects.”
• “Writing tests drives a framework to think about functionality. Mock Objects provides a framework for making assertions about those relationships and for simulating responses.”

Section 4 of the paper discusses Mock Objects in practices, detailing some guidelines for how to use them properly:

• “Only mock types you own”. Matt mentioned this one at our book club the other day in the context of skinning and wrapping APIs.
• “Don’t use getters”. Why? “Getters expose implementation, which increases the coupling between objects and allows responsibilities to be left in the wrong module. Avoiding getters forces an emphasis on object behaviour rather than state..”. I was taught not to use getters by Nick and I find myself discussing it often with each pair.
• “Specify as little as possible in a test”…”One of the risks with TDD is that tests become ‘brittle’, that is they fail when a programmer makes unrelated changes to application code.” This is on of the most common criticisms of TDD that I have heard from other developers. The paper goes onto say that the cause is that “…(the tests) have been over-specfied to check features that are an artefact of implementation, not an expression of some requirement in the object.” I’ve written tests that fall into in this category and I think it can be quite challenging to avoid doing so. Steve Freeman, one of the authors of the paper, blogged about this situation happening in a Coding Dojo earlier this year.
mocking  testing  bestpractices  tdd 
january 2017 by cdzombak
Mock Roles, not Objects
Mock Objects is an extension to Test-Driven Development that supports good Object-Oriented design by guiding the discovery of a coherent system of types within a code base. It turns out to be less interesting as a technique for isolating tests from third-party libraries than is widely thought. This paper describes the process of using Mock Objects with an extended example and reports best and worst practices gained from experience of applying the process. It also introduces jMock, a Java framework that embodies our collective experience.
filetype:pdf  testing  tdd  bestpractices  mocking 
january 2017 by cdzombak
google/wycheproof: Project Wycheproof tests crypto libraries against known attacks.
Project Wycheproof tests crypto libraries against known attacks. It is developed and maintained by members of Google Security Team, but it is not an official Google product.

At Google, we rely on many third party cryptographic software libraries. Unfortunately, in cryptography, subtle mistakes can have catastrophic consequences, and we found that libraries fall into such implementation pitfalls much too often and for much too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades' worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that cryptographic loopholes can be resolved by the same means.

These observations have prompted us to develop Project Wycheproof, a collection of unit tests that detect known weaknesses or check for expected behaviors of some cryptographic algorithm. Project Wycheproof provides tests for most cryptographic algorithms, including RSA, elliptic curve crypto and authenticated encryption. Our cryptographers have systematically surveyed the literature and implemented most known attacks. We have over 80 test cases which have uncovered more than 40 bugs. For example, we found that we could recover the private key of widely-used DSA and ECDHC implementations.

While we are committed to develop as many attacks as possible, Project Wycheproof is by no means complete. Passing the tests does not imply that the library is secure, it just means that it is not vulnerable to the attacks that Project Wycheproof tests for. Cryptographers are also constantly discovering new attacks. Nevertheless, with Project Wycheproof developers and users now can check their libraries against a large number of known attacks, without having to spend years reading academic papers or become cryptographers themselves.
security  testing  cryptography  lang:java  is:repo 
december 2016 by cdzombak
Personal Unit Testing Road Blocks | chemistcodingios
Notes on someone's unit testing journey, in response to Fatal Error S1E9.
december 2016 by cdzombak
How to Do XCTestCase tearDown Wrong (and Right)
Let’s boil this down to a rule-of-thumb:

Every object you create in setUp should be destroyed in tearDown.

Remember, that’s not the only thing to do in tearDown. It’s there so we can reset things back to a clean state. What’s part of our global state? This includes:

• Method swizzling
• File system
• User defaults
• Database
• Keychain
• Really, any sort of Dependency Injection via Ambient Context
testing  xctest  lifecycle  XCTestCase  memorymanagement 
october 2016 by cdzombak
Test Doubles: Mocks, Stubs, and More ·
Nice introduction to different types of test doubles, plus key concepts like DI and "don't mock what you don't own".
testing  testdoubles  mocking  stubbing  documentation  ocmock  ocmockito  dependency-injection 
august 2016 by cdzombak
Behavior-Driven Development ·
As the first word in BDD suggests, you should no longer focus on tests, but you should instead focus on behaviors. This seemingly meaningless change provides an exact answer to the aforementioned question: you should test behaviors.
testing  bdd 
august 2016 by cdzombak
A Response to “Why Most Unit Testing is Waste” | Henrik Warne's blog
In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature. Coordinating code often requires a lot of (mocked) context for unit testing, but the tests themselves are not very interesting. This type of code does not benefit a great deal from unit testing, and is instead better tested in integration testing.

also, the author who wrote, "why most unit testing is a waste" weighs in, in the comments.
august 2016 by cdzombak
MVVM Architecture Question · Issue #138 · thoughtbot/Tropos
A comment describing the use of MVVM architecture in a given application.
The whole point is to move as much code and logic out from anything View specific. This makes that code much easier to unit test. It can also lead to reusable Controllers and ViewModels.
testing  mvvm  bestpractices  software_architecture 
august 2016 by cdzombak
ashfurrow/C-41: C-41 is an application to help people develop film at home by providing a series of "recipes" for photographers to use.
C-41 is an application to help people develop film at home by providing a series of "recipes" for photographers to use.

The app demonstrates how to use Core Data, unit tests, ReactiveCocoa, and Model-View-ViewModel. Pull requests are welcome.
coredata  software_architecture  reactivecocoa  mvvm  testing  is:repo 
august 2016 by cdzombak
venmo/DVR: Network testing for Swift
DVR is a simple Swift framework for making fake NSURLSession requests for iOS, watchOS, and OS X based on VCR.

Easy dependency injection is the main design goal. The API is the same as NSURLSession. DVR.Session is a subclass of NSURLSession so you can use it as a drop in replacement anywhere. (Currently only data tasks are supported.)
ios  nsurlsession  networking  testing  is:repo 
july 2016 by cdzombak
Network Testing in Swift with DVR — Hi, I’m Sam
DVR is a project I recently wrote at work. It’s heavily inspired by VCR for Ruby. There’s a few key differences though.

Unlike VCR or other Objective-C implementations, doesn't have any global state and doesn't swizzle or monkey-path things to get in place. It's intended to by used by dependency injection.

DVR provides an NSURLSession subclass. When you try to make a request with the session, it will look for a prerecorded session. If one is found, it will play it back. If not, it will record it and then let you know you need to add the recording to your project.
testing  networking  nsurlsession  ios 
july 2016 by cdzombak
Snapshot Tests + Blinking Cursors — Medium
Nothing in the test class seemed amiss. The build server was functioning normally. The test passed on my machine. Ready to give up, hours later, it finally dawned on me.
The cursor. The damn blinking cursor.
ios  testing  uitextfield  ci  ui_testing  screenshots 
july 2016 by cdzombak
Quick/ at master · Quick/Quick
Whether you're using XCTest, Quick, or another testing framework, you can write effective unit tests by following a simple pattern:

1. Arrange
2. Act
3. Assert
testing  bestpractices  xctest  bdd  tdd 
june 2016 by cdzombak
Snapshot Testing ·
View-based testing means verifying that what the user sees is what you want the user to see. Doing this means being able to ensure that different versions of your views, or different states of your views, continue to look the same. View-based testing can be used to provide a high-level test covering a lot of use cases surrounding an object.

How It Works

FBSnapShotTestCase takes a UIView or CALayer subclass and renders it to a UIImage. This snapshot is used to create tests that compare a saved snapshot of the view/layer and the version generated by your test. When it fails, it will create a reference image of the failed test, and another image to show the difference of the two.
ios  testing  uikit  cocoa_touch  FBSnapShotTestCase 
june 2016 by cdzombak
Better Specs { rspec guidelines with ruby }
On the web there are many resources that give complete overview of _what_ you can do with RSpec. But there are fewer resources devoted to how to create a great RSpec test suite.

Better Specs tries to fill this gap by collecting most of the "best practices" that other developers learn through years of experience.
rspec  testing  bdd  documentation  bestpractices 
june 2016 by cdzombak
Home · testdouble/contributing-tests Wiki
This wiki presents some notes on testing.

That's an understatement. This looks to be a very solid resource on TDD.
github_wiki  testing  tdd  bdd  bestpractices  documentation 
june 2016 by cdzombak
describe vs. context in rspec – Lab Matrix
The purpose of “describe” is to wrap a set of tests against one functionality while “context” is to wrap a set of tests against one functionality under the same state.
testing  rspec  bdd 
may 2016 by cdzombak
5 Questions Every Unit Test Must Answer — JavaScript Scene — Medium
Lots of good advice about unit testing and TDD in here. This is not at all JS-specific.
Next time you write a test, remember to answer all the questions:

• What are you testing?
• What should it do?
• What is the actual output?
• What is the expected output?
• How can the test be reproduced?
testing  tdd  bestpractices 
may 2016 by cdzombak
UI Testing in Xcode 7 ·
Good discussion on ins & outs of UI testing in Xcode.
xcode  ui  testing  xctest  accessibility 
april 2016 by cdzombak
Mocking Classes You Don't Own ·
To accomplish this we will follow my coined acronym, IDEPEM. This stands for inject dependencies, everything's a protocol, equatable mocks.
testing  swiftlang  protocols  mocking  nsurlsession 
march 2016 by cdzombak
Transitioning From Objective C to Swift in 4 Steps – Without Rewriting The Existing Code | Code Voyagers
the most significant takeaway (aside from basic interop notes):
In Swift the only way to write testable code is by making dependencies explicit and injectable.

there is no mocking. this is not a bad thing.
swiftlang  objective-c  interop  testing  mocking  ocmock 
february 2016 by cdzombak
Partial functions in Swift, Part 2: Catching precondition failures
in which we use Mach exception handlers to rewrite precondition statements into catchable failures in order to test them properly.
mach  testing  swiftlang  precondition  assertions  error_handling  xctest 
february 2016 by cdzombak
SwiftKit/Cuckoo: First boilerplate-free mocking framework for Swift!
Cuckoo was created due to lack of a proper Swift mocking framework. We built the DSL to be very similar to Mockito, so anyone using it in Java/Android can immediately pick it up and use it.

## How does it work

Cuckoo has two parts. One is the runtime and the other one is an OS X command-line tool simply called CuckooGenerator.

Unfortunately Swift does not have a proper reflection, so we decided to use a compile-time generator to go through files you specify and generate supporting structs/classes that will be used by the runtime in your test target.

The generated files contain enough information to give you the right amount of power.
mocking  testing  swiftlang  lang:swift  ios  osx  is:repo 
january 2016 by cdzombak
KnuffApp/Knuff: The debug application for Apple Push Notification Service (APNs).
Knuff: The debug application for Apple Push Notification Service (APNs).


• Send push notifications to APNS (Apple Push Notification Service) very easily (no configuration needed at all)
• Load / Save documents including token and JSON payload
• Grabs the certificate right from your keychain
• Get the device token automatically; forget about manually retrieving the device token through logging or similar techniques. Even more useful when not in sandbox mode
• Support for error response codes
• Detects Development/Production environment automatically
• Supports universal certificates
• Custom JSON payloads
• Identity export to PEM format (⌘ + E)
apple  notifications  ios  testing  tool  apns  osx  via:iosdevweekly  is:repo 
january 2016 by cdzombak
The Big List of Naughty Strings is a list of strings which have a high probability of causing issues when used as user-input data.

I have put together these strings to create Naughty Keyboard – a very simple iOS app that gives you access to a custom keyboard to use these strings to test your application.

Big List of Naughty Strings:
testing  ios  is:repo 
august 2015 by cdzombak
The Big List of Naughty Strings is an evolving list of strings which have a high probability of causing issues when used as user-input data. This is intended for use in helping both automated and manual QA testing;

See for an iOS keyboard
testing  is:repo 
august 2015 by cdzombak
A Matcher Framework for Swift and Objective-C
ios  testing  swiftlang  objective-c  is:repo 
july 2015 by cdzombak
We've Got You Covered | Big Nerd Ranch
One of Xcode 7’s new features is in-line display of code coverage metrics. Yay? That’s a pretty dull way of describing a nice feature. Code coverage figures out which lines of code have been executed while running unit tests, and now Xcode shows you information about this coverage in the UI.
xcode  testing  llvm 
july 2015 by cdzombak
A Closer Look at Test Spies
A discussion of some tradeoffs of test spies vs. mocks, and the new-in-RSpec-3.1 `spy` method.
testing  test_spies  mocking  rspec 
june 2015 by cdzombak
Spy vs Spy
Test spies allow clean separation of test phases; and they allow reusability of stub objects without verifying the same things repeatedly.
testing  test_spies 
june 2015 by cdzombak
With the latest support library release 22.2.0, we added an @VisibleForTesting…
With the latest support library release 22.2.0, we added an @VisibleForTesting annotation to support-annotations[0]. This annotation denotes that a class, method or field has its visibility relaxed, so that it is more widely visible than otherwise necessary to make your code more testable.

Setting aside the debate around testing _only_ the public interface, this is pragmatic and would be useful. It should raise a red flag during code review, but it isn't necessarily always bad.
testing  android  java  annotations 
june 2015 by cdzombak
Quick is a behavior-driven development framework for Swift and Objective-C.
bdd  testing  objective-c  swiftlang  is:repo 
may 2015 by cdzombak
« earlier      
per page:    204080120160

related tags

@patch  accessibility  android  annotations  antipatterns  apns  apple  appstore  aspectoriented  assertions  async  bdd  benchmarking  bestpractices  ci  circuit_breaker  cocoa  cocoa_touch  code_coverage  code_style  coredata  cryptography  culture  data  dataset  dependencies  dependency-injection  dependency_management  design  designpatterns  development  diy  documentation  elixir  embedded  entr  erlang  error_handling  expecta  faulttolerance  FBSnapShotTestCase  filetype:pdf  github_wiki  golang  goos  html  iap  inheritance  interop  interviewing  ios  is:repo  is:video  isolation  itunesconnect  java  javascript  jekyll  jenkins  kvo  lang:go  lang:java  lang:swift  lifecycle  llvm  logging  mach  MagicMock  management  memorymanagement  mocking  mockito  mockobjects  mvvm  names  naming  networking  nil  nimble  notifications  NSErrorPointer  NSURLConnection  nsurlsession  objective-c  ocmock  ocmockito  octopress  oop  organization  osx  packaging  pc  php  playgrounds  precondition  productivity  programming  project_layout  protocols  python  quick  quickcheck  rails  reactivecocoa  refactoring  remote_work  robolectric  rspec  ruby  runloop  scala  screenshots  security  semian  sentestkit  singleton  software_architecture  stability  strings  stubbing  style  swiftlang  tdd  tell-dont-ask  testdoubles  testing  test_spies  text  time  tool  tools  toyota  travisci  ui  UIAutomation  uikit  uitextfield  uiviewcontroller  ui_testing  unicode  unittest  utf8  validation  via:andrewsardone  via:brentsimmons  via:github  via:henrik  via:iosdevweekly  via:mattb  via:mikelinington  via:osteslag  web_dev  work  workspace  xcode  xcode6  xcode7  xcodebots  xctest  XCTestCase  XCTestExpectation  XCTestWaiter  XCTKVOExpectation  XCTNSNotificationExpectation  XCTPredicateExpectation 

Copy this bookmark: