We've all been there: all of your test cases worked the night before but when it comes time to run the demo you realize you missed something. In college, I had to write Sub Hunter in assembly and those pesky submarines kept launching missiles after I depth charged them back to hell. The TA didn't notice either. It wasn't until later that I learned about the magic of peer review. Not that fewer bugs sneak across the unit test border, you just feel better because someone else missed the problem too.

Luckily for Christian's friends, he's on patrol. When one of his friends ended up on a randomly assigned project team, Christian took a look at some of the code. Apparently "Karl", the person in charge of the authentication module, wasn't too good at taking criticism as long as the unit test passed.

If there was only one user ("testuser") in the database, the test in question worked and quickly at that. 

  public void Authenticate( string username, string passhash )
  {
      SqlDataReader source = _Database.Query("SELECT * FROM users;");

      while ( source.Read() )
      {
          if ( source["user"].ToString() == username
          &&   source["pass"].ToString() == passhash )
          {
              this.authenticated = true;
          }
          else
          {
              this.authenticated = false;
          }
         
      }
  }

 

When our hero put 10K random entries in the database, the unit test was orders of magnitude slower but it still passed and the demo still worked. Karl was enlightened only when Christian made sure that "testuser" wasn't the last entry in the database. After that, he and Karl spent some time talking about the WHERE clause.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!