- "Write tests. Not too many. Mostly integration."
- Integration tests strike a great balance on the trade-offs between confidence and speed/expense. This is why it's advisable to spend most (not all, mind you) of your effort there.
- biggest thing you can do to write more integration tests is to stop mocking so much stuff
- When you mock something you're removing all confidence in the integration between what you're testing and what's being mocked.
Instead to find where org.w3c.dom comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q org.w3c.dom; then echo $i; fi ; done
text/html; vimprobtab.sh %s &; test=test -n "$DISPLAY"; needsterminal;
text/html; w3m -I %{charset} -T text/html; copiousoutput;
The first entry tests that X is running, and if it is, it hands the file to vimprobable. The default, however, is determined by the copiousoutput tag. So, in mutt it is just a matter of hitting v to view the attached HTML and then m to send it to mailcap
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke command_name, but do not invoke command_name.
example:
if [ ! `command -v iconv` ]; then echo "not exists"; fi
E. Pinheiro, W. Weber, and L. Barroso. Proceedings of the 5th USENIX Conference on File and Storage Technologies, page 2--2. Berkeley, CA, USA, USENIX Association, (2007)