ScalaCheck 1.5 Version 1.5 of ScalaCheck is now available. ScalaCheck is a tool for automatic unit testing of your Scala and Java programs, developed by Rickard Nilsson. ScalaCheck allows you to define general properties about your code units, while the tool handles all test data generation for you: you can run thousands of unit tests automatically without writing and maintaining an endless number of test cases. Version 1.5 of ScalaCheck introduces support for Scala 2.7.2 and various minor feature additions. ScalaCheck's highlights Properties are tested automatically, with test data generated by ScalaCheck. A small example, using the Scala interpreter with ScalaCheck on the path: sbaz update sbaz install scalacheck If you already have an earlier version of ScalaCheck installed, you just need to run: sbaz upgrade
Bandwidth Monitoring Tools for Ubuntu Users If you're new here, you may want to subscribe to my RSS feed and if you have questions related to your ubuntu system post question to our forums. Thanks for visiting! Sponsored Link Bandwidth in computer networking refers to the data rate supported by a network connection or interface. One most commonly expresses bandwidth in terms of bits per second (bps). Bandwidth represents the capacity of the connection. Here is the list of bandwidth monitoring tools for your network bandwidth bmon bwbar bwm bwm-ng iftop iperf ipfm speedometer cbm ibmonitor pktstat mactrack MRTG Cacti Now we will see each tool separately bmon bmon is a portable bandwidth monitor and rate estimator running on various operating systems. Various output modes exist including an interactive curses interface, lightweight HTML output but also formatable ASCII output Current Stable Version :- 2.1.0 Install bmon in Ubuntu sudo apt-get install bmon This will complete the installation. bmon you should see the following output bwbar bwm bwm
Genetic A/B Testing with JavaScript I’ve long been interested in the concept of A/B testing (Also called split testing). It’s a simple concept that should sit will with most mathematically-inclined types: You have a baseline interface in which you adjust a single variable, at random, for each user that visits your application. After a given amount of time you should be able to see if certain variables affect how your users behave (either negatively or positively). A product was recently released called SnapAds which allows its users (advertisers) to permute different variations of an ad and display different versions to users, based upon how well they perform over time. But that’s not what I was interested in, specifically (even though it is a cool idea). The team that created this also created another product a while back that never saw a full release: Genetify. Genetify provides a demo on their site showing the basics of how it works along with a simple text tutorial. <script>genetify.vary();</script> Comments are closed.
test Google's framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, value- and type-parameterized tests, various options for running the tests, and XML test report generation. Getting Started After downloading Google Test, unpack it, read the README file and the documentation wiki pages (listed on the right side of this front page). Who Is Using Google Test? In addition to many internal projects at Google, Google Test is also used by the following notable projects: The Chromium projects (behind the Chrome browser and Chrome OS) The LLVM compiler Protocol Buffers (Google's data interchange format) If you know of a project that's using Google Test and want it to be listed here, please let googletestframework@googlegroups.com know. Google Test-related open source projects
Functional Programming Unit Testing - Part 2 In the previous post, we talked about some of the basics of functional programming unit testing. That post mostly focused around HUnit, which is a traditional xUnit testing framework. This time, let's focus on type-based property testing, which is to create specs which assert logical properties about a function, and then to generate data to test in an attempt to falsify these assertions, through the use of a tool called QuickCheck. Much like the traditional xUnit frameworks, this tool helps us flush out the specifications of our software through the use of tests. Unlike the xUnit frameworks, however, this framework allows us to create generators to help flush out our behaviors and capture our edge cases as we look for ways to falsify our tests. But, before we continue, let's get caught up to where we are today: Part 1 - xUnit Frameworks - HUnit Introducing QuickCheck Let's first walk through a simple example of how QuickCheck works before we move onto some more interesting ones. #light
Functional Programming Unit Testing - Part 4 In our previous installment, we talked about bringing together the traditional xUnit tests and QuickCheck property-based tests together in a single cohesive step. For this installment, let's talk about test coverage. But, before we continue, let's get caught up to where we are today: Code Coverage Code coverage is an important metric used as part of our design process to describe to what degree our source code has been tested. What do we consider as part of the criteria when we're calculating code coverage? Function coverage All functions in the program called? Of course some of these are connected in some way such as the following: Decision coverage includes statement coverage since exercising every branch must lead to exercising every statement. Where should we focus? We can use above metrics to determine how well we're writing our tests for our applications. Code Coverage with Haskell Program Coverage (HPC) The HPC tool is designed to give you the following metrics: --file Encryption.hs
The Invisible Branch Full statement coverage may be necessary for good testing coverage, but it isn't sufficient. Two places where statement coverage will be inadequate are branches and loops. In this episode, we'll look at branches, and specifically the differences between statement coverage and branch coverage. Let's consider a case where branch coverage and statement coverage aren't the same. bool DeathRay::ShouldFire(EvilOverLord& o, Target& t) { double accumulated_rage = 0.0; if (o.IsBerserk()) accumulated_rage += kEvilOverlordBerserkRage; accumulated_rage += o.RageFeltTowards(t); return (accumulated_rage > kDeathRayRageThreshold);} But what if DeathRay should fire at this Target even with a non-berserk Overlord? if (o.IsBerserk()) { accumulated_rage += kEvilOverlordBerserkRage; } else { } Why do we add an else clause if it doesn't actually do anything? Remember to download this episode of Testing on the Toilet and post it in your office.
JavaScript Testing Does Not Scale (This is a follow-up on my portion of the More Secrets of JavaScript Libraries panel at SXSW.) It’s become increasingly obvious to me that cross-browser JavaScript development and testing, as we know it, does not scale. jQuery’s Test Suites Take the case of the jQuery core testing environment. Next, we have a test suite that serves the regular XHTML test suite with the correct mimetype (application/xhtml+xml). Both of those tweaks (one with correct mimetype and one with no doctype) would also need to be done for the offset test suite. We have another version of the default jQuery test suite that runs with a copy of Prototype and Scriptaculous injected (to make sure that the external library doesn’t affect internal jQuery code). Finally, we’re working on another version of the suite that manipulates the Object.prototype before running the test suite. We’re in the initial planning stages of developing a pure-XUL test environment (to make sure jQuery works well in Firefox extensions).
Riffing on Romance, was Re: My Modernism Hurts --- In postmodernprogramming@yahoogroups.com, "mfeathers256" >I remember once [...] Kent > was talking about the Money example he used in the TDD book. I'm reminded of one of Heinlein's juveniles ("Tunnel in the Sky"). (When you get bored, search ahead to [*] to reach the punchline.) So, what can we do with this as regards software? During a discussion of a different episode on the team wiki I described how working on complicated imperative loops like that gives me the same feeling as I get when from time to time I have to run a motorcycle engine with a cover removed: there are all these hard, sharp, choppy, crushy bits whizzing around at high speed just ready to hurt me badly (and destroy the engine) if I go fiddle with them in even slightly the wrong way. So my pair and I wrote a FunctionObject class and fitted it out with a fixedPoint() method, rewrote the original code in terms of it (the nasty looping method became almost a one-liner) and made our change (now very simple to do).
Code Coverage of Clojure Code Since pulling in Dmitry's test-compile mojo, and adding a test script runner mojo to the clojure-maven-plugin I thought I'd try something fun like running the maven emma plugin against a very simple test project. I was pleasantly surprised to see some fairly useful (ish) coverage data come back: You can easily see coverage information for your code, even if you end up trying to decipher clojures generated class names. You even get fairly useful breakdown on the class detail, even if there's only the one method on each class: Once you've installed the clojure-maven-plugin, simply configure the plugin in your pom.xml: org.clojure clojure-maven-plugin clj-web-crawler smx-api src/test/java/test.clj compile test Adding these simple automated compile, test, and coverage processes to a clojure's impressive arsenal clojure already offers gives me a greater level of trust to experiment and use the young language in projects destined for a production environment. Comments (0) Add Comment