Already a few days ago I got tagged by Manuel Pichler and Gaylord Aulke. I could not post as I was really sick the last two weeks. Today is the first day where I see light at the end of the tunnel and I feel good enough to answer the questions.

So you really want to know seven things about me ? Well - you asked for it

1. I earned my first money by creating a blackmarket in secondary school for sexual explicit material, which I bought cheap and sold expensive. This was one of the reasons I had to leave this school.

2. My first love was named Commodore 64. I teached myself Assembler and started to rip off music from games, creating my own demos.

3. My holidays are usually spent in croatia as my beloved wife was born there.

4. I work with a bunch of developers in lithuania, and hey - these guys (and girls!) are really good.

5. Recently I donated my book collection of > 2500 science fiction and fantasy books to a shop where handicapped sell the books to life from that.

6. Although I was born in bavaria my limit are 3 litres of beer, after that I am really really drunk.

7. I can’t stand cold weather - I feel well at an average of 26+ degrees. Oh, do you remember 4. ? In .lt the winters are really really REALLY cold and I hate it.

So - now my turn. Not so easy. I think nearly everybody who I know was already tagged, therefore - sorry about that - I need to tag a bunch of german people who I think are not yet tagged by this meme.

Here we go:

1. Nils Langner for teaching PHP
2. Thorsten Rinne just to remember him that he still ows me a self cooked thai menu.
3. Xenjo because I am curious what he would write….
4. Ralf Eggert to support his upcoming Zend Framework book (in german only)
5. Christopher Kunz who runs partly my servers for swoodoo and takes care about themeven from holiday. Thanks Chris !
6. Tomas Liubinas one of the .lt developers I mentioned and actually he was part of the team who won in plat-forms contest.
7. Max Horvath for… hmm… I still wait for the pics

These are the rules apparently:

Link your original tagger(s), and list these rules on your blog.
Share seven facts about yourself in the post - some random, some weird.
Tag seven people at the end of your post by leaving their names and the links to their blogs.
Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

Last December, when I was in Australia and started to work on the Object_Freezer code, I "dived into" Bazaar (bzr) and learned the value of local commits as they allow me to work offline, e.g. when disconnected during travel.

Thanks to bzr-svn, I can now work offline for PHPUnit development as well.

Here is my setup:

Firstly, setup a local shared repository for storing your branches in and checkout the trunk:

sb@ubuntu ~ % bzr init-repo --rich-root-pack phpunit
Shared repository with trees (format: rich-root-pack)
Location:
  shared repository: phpunit

sb@ubuntu phpunit % bzr checkout svn+ssh://sb@svn.phpunit.de/var/svn/phpunit/phpunit/trunk

I still use Subversion natively to deal with the release branches:

sb@ubuntu phpunit % svn co svn+ssh://sb@svn.phpunit.de/var/svn/phpunit/phpunit/branches/release/3.4

sb@ubuntu phpunit % svn co svn+ssh://sb@svn.phpunit.de/var/svn/phpunit/phpunit/branches/release/3.3

The bzr info command shows that the local Bazaar branch is related to a remote Subversion branch:

sb@ubuntu phpunit % bzr info trunk
Repository checkout (format: rich-root-pack)
Location:
  repository checkout root: trunk
        checkout of branch: svn+ssh://sb@svn.phpunit.de/var/svn/phpunit/phpunit/trunk
         shared repository: .

Next, create a feature branch and hack away:

sb@ubuntu phpunit % bzr branch trunk feature
Branched 205 revision(s).

(hack, hack, hack)
sb@ubuntu feature % bzr commit -m "blah blah blah"
(hack, hack, hack)
sb@ubuntu feature % bzr commit -m "blah blah blah"

sb@ubuntu trunk % bzr update
sb@ubuntu trunk % bzr merge ../feature
sb@ubuntu trunk % bzr commit -m "Message for SVN commit."

At least for the foreseeable future, I will not migrate the central Subversion repository of the PHPUnit project to Bazaar as Subversion is a good choice for implementing a centralized workflow and is well understood by those of my users that use PHPUnit from a Subversion checkout, for instance using svn:externals to integrate it with their own software configuration management.

In version 5.2 we're introducing a new set of API which for VB developers. Let's start with...

Why?

We already have VB support in Isolator. It's already there in full glory in Natural and Reflective mocks. The difference starts with AAA. Because the C# AAA API is based on Lambda Expressions, VB users can use only part of it. I won't go into details, but it's because of the VB support for Function(Of T) but not for Action(Of T). So we could wait for the next VB version (in VS2010) to come out. We decided not to wait.

We see Arrange-Act-Assert as the way to go. We're adding features to the C# API all the time, and we don't want to see VB developers left behind. Truth is, we see a big opportunity in the VB market, to help introduce VB developers to unit testing and isolation with Isolator.

So here comes the new VB API. It is also AAA in nature. There's a new assembly called Typemock.Isolator.VisualBasic that you reference from your VB test project, and presto! you have all the features of our AAA C# API in VB. Obviously going forward all the neat features going into both versions.

Here's an example of a the new API:

<TestMethod()> Public Sub FakeVerification_HappenedWithExactArguments()
        ' Create and set up a fake object
        Dim fakeProduct As Product = FakeInstance(Of Product)()

        ' Fake a return value
        Using TheseCalls.WillReturn(100.0F)
            fakeProduct.CalculatePrice(0)
            Dim dummy As Single = fakeProduct.Price
        End Using

        ' Perform a calculation on the product
        Dim handler As New ProductHandler()
        handler.CalculateProductsYearlyNetWorth(fakeProduct, 100, 4000)

        ' Verify that CalculatePrice() was called during the calculation with the correct number of items
        Using AssertCalls.HappenedWithExactArguments
            fakeProduct.CalculatePrice(100)
        End Using
End Sub

The C# developers can identify the FakeInstance (which is similar to Fake.Instance). The WillReturn also seems familiar but it comes in a Using block. The equivalent of Isolator.Verify is AssertCalls, which is also used in a Using block. A nice VB API feature is that with the Using block you can have multiple functions and properties returning the same value, or use the AssertCalls block for multiple functions. (for C# developers who finally feel VB envy - you can reference this assembly and use it as well).

One difference to note in the VB version of WillReturn. It is not type-safe, meaning, the compiler allows you to write instead of the Single value 100.0F, let's say a string "100.0F", although CalculatePrice returns a Single. Isolator will find this at runtime, and will throw an exception.

Stay tuned. There's more to come.

In an effort to end the year on a high note, I have released a first preview release of PHPUnit 3.4 today.

The highlights of this new release series include:

• Support for optionally executing each test using a separate PHP process
• Support for exploiting dependencies between tests to improve defect localization
• Support for mocking SOAP web services based on their WSDL specification
• A rewrite of the code generator that is used by the mock object system

The complete ChangeLog is also available.

PHPUnit 3.4.0alpha1 is not feature-complete and should not be used in production.

Please have a look at the new features and test whether this new version of PHPUnit can run your test suite without problems.

In his blog Derik Whittaker wrote about a recent experience he had while teaching developers how to write unit tests using Isolation framework.

The post titled "Teaching someone to test using an Isolation Framework" describes how someone can use pair programming in order to help fellow developer to learn how to approach the subject of writing isolated unit tests.

I found the tips in the post extremely useful when teaching a new subject to a fellow co-worker:

• Slowdown, slowdown, slowdown
• Make NO assumptions, teach as if they know nothing
• Have them drive
• Provide examples both with and without the Isolation framework
• Don't let them skate by
• Turn off any coding tools such as ReSharper (or the likes) and do NOT use shortcuts

I especially liked the usage of a tool called Keyboard Jedi (written by Roy) so that your pair won't get lost when you start using keyboard shortcuts.

Go read it now

Derik Whittaker posted on "Teaching someone to test using an Isolation Framework". I wrote about this experience before, and I like the points Derik describes during his teaching session.

Derik has chosen to go with Rhino, but maybe going with Isolator would help speed things up next time:)

In my last post, I detailed the process of writing the first unit-test. So now you got your fingers dirty, and you're confident. Now you want to start unit-testing in a more managed, process-oriented way. How do you do it?

Let's say, for example, you have Team System in place, and you use it for source control and tracking work items. Obviously, you can do much more with Team System, but let's start with the basics. You've tasted enough unit-testing to feel that everyone can benefit from them. Where would you start?

Here are my thoughts. This is what I would consider the essential setup to start with.

1. Check in whatever tests you already have, and start checking in any new test code. You don't want to lose what you already have. Even if you don't have a continuous integration system in place (see the next step), you can run the tests manually on your (or any) machine anytime.
2. Use a continuous build system. In Team System it's Team Build, or you can use CruiseControl.Net, TeamCity, or any another tool. Whenever someone checks in code, the build starts automatically and reports success/failure. Without running the tests, it would just give a compilation status report, which is a good starting point. The entire build process, from beginning to end should be automatic, and should not have anyone intervening, or fixing just one thing to work. Think of it as a pulse of the project. If the build fails, fix it pronto. Don't let the poor team lose it's pulse.
3. Add to the build script (or integration script) running of tests. Any automated test should run within the build cycle. The build report should report the results of the tests.
4. Make a habit of looking at the test report. If the build fails because of test failure, consider it good feedback. It motivates you to do something - fix the test, change it, delete it, or even ignore it or leave it there. You need to be aware of the test results. From there you can improve.

Once you have this setup, you can now start improving other stuff, like say, prioritizing or tracking your progress. In the next posts, I'll discuss what to track, and how to manage your unit-tests within a process.

Following are instractions to get full functional source environment of JSystem:

read more

Following are instractions to get full functional source environment of JSystem:

read more

• Fixed #425: Code Coverage fails if array from Xdebug is not sorted. [4370]
• Fixed #660: PHPUnit_Framework_Assert::getObjectedAttribute() fails for inherited private attributes. [4385]
• Implemented #659: Implement workaround for PHP bug #46064. [4360]

There are a lot of good tutorials on how to start Test driven development (TDD) that help understanding how he can start using this software development methodology. Unfortunately most of those tutorials explain how to write simple unit test to test some imaginary class and do not explain using mocking frameworks as part of the tutorial.

Many newcomers to the Test Driven development world do not learn about mocking framework mainly because of the misperception that mocking is difficult to use and an unnecessary complication of tests.

Hopefully in the following post I would be able to dispel this notion.

The background story

You are a developer working as part of a team developing a new CRM system.

Today you are tasked with adding new functionality to an Order object - When a ProductId is added to a newly created Order the TotalPrice property of that order shall be equal to the product's Price.

The only problem is that the developer that is responsible of the Product object didn't finish writing the data access code yet.

Note that even if the product object was fully implemented it's we don't want to create a new database every time we run our tests.

So what is TDD?

If you haven't heard of TDD before I suggest you go and read the definition of Test Driven Development on Wikipedia:

Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.

Test-Driven Development is related to the test-first programming concepts of Extreme Programming, begun in 1999,[1] but more recently is creating more general interest in its own right.[2]

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.[3]

TDD can be summarized as a set of the following actions:

1. Write a test that fail
2. Write code to make the test pass
3. Make sure that all of the previous tests still pass
4. Refactor your code
5. Repeat (if necessary)

[Image from Yet Another Language Geek blog - Musings on Software Testing]

How to start - writing the test

In order to start TDD we'll need the following:

• Editor to write your code - most windows developer prefer to use Visual Studio but feel free to use whichever editor/IDE you usually use
• Unit testing framework - you can go and download NUnit it's free and easy to use.
• For the purpose of this tutorial you will also need Typemock Isolator - you can get a 30 day evaluation copy from our download page.

Create a new class library (dll) project and add a reference to nunit.framework.dll.

And now we can write our first test:

   1:  [TestFixture]    

   2:  public class OrderTests    

   3:  {    

   4:      [Test]     

   5:      public void AddProduct_AddOneProductToOrder_OrderTotalCostEqualProductPrice()    

   6:      {    

   7:          var productPrice = 15.00;        

   8:          var order = new Order();    

   9:          order.AddProduct("product1");

  10:          Assert.AreEqual(productPrice, order.TotalCost);

  11:      }    

  12:   }       

Running the test above cause an exception to be thrown from line 9. because product data access is not implement yet running Product.Retrive throws an unimplemented exception.

Now we have to decide what to do:

1. Complain that the Product class was not finished yet.
   


2. Use Fake product instead.
   

Faking It - how to write your first mocked object

• Download Typemock Isolator and install it on your computer.
  


• Add references to Typemock.dll & Typemock.ArrageActAssert.dll
  


• read below
  

In this test we want to Fake the static call Product.Retrive so that it would return a product. Using Isolate.WhenCalled we can define that behavior

   1:  [Test]     

   2:  public void AddProduct_AddOneProductToOrder_OrderTotalCostEqualProductPrice()    

   3:  {    

   4:      var productPrice = 15.00;var p = new Product("product1");    

   5:          

   6:      var p = new Product("product1"); 

   7:      p.Price = productPrice;   

   8:      Isolate.WhenCalled(() => Product.Retrieve(string.Empty)).WillReturn(p);    

   9:       

  10:      var order = new Order();    

  11:       

  12:      order.AddProduct("product1");    

  13:          

  14:      Assert.AreEqual(productPrice, order.TotalCost); 

  15:   }

On lines 6-8 we create a new Product and tell Isolator to return it when Retrieve method being called.
Back to TDDWhen running the test another exception is thrown - because we haven't implemented AddProduct functionality yet.

So we write a simple implementation to fix our test:

   1:  public class Order  

   2:  {  

   3:      public double TotalCost { get; set; }  

   4:      public void AddProduct(string productId)

   5:      {  

   6:          var product = Product.Retrieve(productId);

   7:          TotalCost += product.Price;  

   8:      }  

   9:  }

Note that AddProduct currently only increase the amount of the order's total cost, because TDD means that you write only the code required to pass the test. In the future we'll add tests to check that the product was added to our Order as well.

Now our test finally pass. Congratulation not only do you know how to write unit tests you have witnesses faking of objects as well.

Not too hard now is it?

This week I met with a prospect, who, low and behold, is a developer. And we jumped into the code. That means that I made him choose a piece of code he wanted to test, and we wrote a unit test for it, using Isolator.

Sounds easy. It took an hour and a half.

This post is about the steps we went through when starting to unit test. It is an example for everyone brave enough to learn how to start unit testing, on his existing code-base. We'll start with a pre-requisite: have a test framework in place. We had to install the MS unit testing tools as part of VS, because it wasn't installed.

1. Pick what to test.

This took about 15 minutes. I emphasize that I want to test logic, meaning ifs/switches and such. Start from there, and build tests around that piece of code. As the first test, I want to test a simple if statement. What we chose is an IF surrounded by a for-each loop.

2. Pick a scenario.

Once you selected a simple enough code to test, it's easy to pick a scenario. If not, go back to step 1, and select simple code that you can think of a scenario for.

3. Write an empty test, naming it after the scenario you are about to test.

This is crucial, especially when pairing. And if not. If at least one of you is inexperienced in writing tests it's easy to go off on a tangent, and naming helps focus. We use this pattern for naming tests:

METHODNAME_WHEN_EXPECTEDRESULT

Where WHEN is the scenario's initial state, which drives it. and EXPECTEDRESULT is what we are going to assert. We usually have one test class per tested class, so there's no need to use the class' name. Make it readable, so everyone who reads it understand what you are testing. Get someone to review the name, or pair with someone. Did I say this is crucial?

4. Write the test's body without any faking code. It MUST assert something.

When we wrote the test, we just invoked the method. If it runs, it's ok, since the test didn't crash, right?

Wrong!

Write an assertion. Even a simple one, like IsNotNull. A failing test that fails because of the assertion. Of course initially the test crashed before getting to the assertion, but after adding some faking code, it didn't and we didn't know if the test really passed. So add an assertion.

5. Run the test.

At this point, I knew it would fail, but I wanted feedback. It crashed somewhere in the database access in EntLib (MS Enterprise libraries). Which led us immediately to the next point:

6. Think. Decide what you want to fake. Then think again. Be sure.

I could fake database calls in EntLib. But do I really want to do it? Why not fake the DAL (Data access layer) objects? They encapsulate more calls, and I'll write less faking code. What helped here is stepping through the code with the debugger, seeing all the method calls, and who's calling who. Isolate where it makes sense.

7. Write the faking code. Understand what you did. Repeat

Adding faking code is easy with Isolator. That doesn't mean it's what you actually meant to happen. So if you come by a type called XYZ collection, make sure it implements IEnumerable before using the collection APIs. After it works, and you build a return value, go back to the tested code. Implement enough faking code that satisfies the tested code, and the scenario. Does the returned collection need to be filled with objects? Initialized objects? Add all the setup code to the test, and make sure you understand what you're doing. Iterate through all the dependencies, and add faking code.

8. Run the test. Recheck if fails. Make corrections.

After completing the entire fake setup, we realized the assertion should be negated. Stupid isn't it? But it just goes to show that after going through the first steps, there's still some thinking to do.

9. The test passes.

Grab a cup of coffee, you earned it. Then test another scenario.

Unit test coverage of developed code can make sure that functionality won't change during refactoring of legacy code, new feature development and more.

Although it might help It is not necessary to use Test Driven Development (TDD) all that is needed is to write unit tests before the actual work (i.e before a major bug fix).

Today I found another use of unit tests - code parallelization.

In his blog - Rick Minerich writes on how a developer can parallelize existing code to improve its performance.

Rick uses a methodology called RASP:

1. Review: Review code to determine if it is a good candidate for parallelization.
2. Anchor: Create a unit test fixture to ensure that the behavior of the to be parallelized code does not change.
3. Separate: Ensure that the to be parallelized code has no shared memory constraints.
4. Parallelize: Minimally refactor for parallelization while leveraging an existing API to do the heavy lifting.

As you can tell from the steps above an important part of the process is creating unit tests to make sure that the existing functionality won't change during the process.

Of course users of TDD do not need to write tests because they already have them written as part of the development process.

Another place where unit tests are a major part of creating high quality code.

The finalists of the 19th annual Jolt Product Excellence Awards have just been announced... and we are honored to report that Sonar is nominated in the Testing Tools category.

The Jolts are presented annually to "define which software development products are ahead of the curve. They honor products that are universally useful, that are simple, yet rich in functionality, or that redefine their product space".

Congratulations to all the finalists, we wish them all the best of luck. Winners will be Announced at SD West 2009 on March 11th 2009. Every product has a chance to win, even the less known ;-)

• Fixed #425: Code Coverage fails if array from Xdebug is not sorted. [4270]
• Fixed #649: Fatal error: Unsupported operand types in /usr/share/php/PHPUnit/Framework/ComparisonFailure/Scalar.php on line 78. [4287]
• Fixed #650: PHPUnit tries to include non-existent bootstrap file. [4303]

Mads Nissen had an issue with Typemock Isolator and Gallio integration
He was kind enough to let us work with him and solve the problem.
Thanks Mads!

In his blog post mentioned above he says:
"First I added most of the TypeMock 5.1 binaries to my buildtools svn repository (no, didn't bother to investigate which files I actually HAD to include - TypeMock Team: It would be nice to have this documented in order to create the smallest possible footprint for this scenario)."

Well Mads is right and here is the list:

• TypeMock.dll (Should be in the GAC)
• Configuration.dll (Should be in the GAC)
• MockWeaver.dll
• ProfileLinker.dll
• namespaces.dat
• typemockconfig.xml
• TypeMock.Configuration.exe
• Typemock.ArrangeActAssert.dll

If you are using MSBuild or NAnt:

• TypeMock.MSBuild.dll
• TypeMock.NAntBuild.dll

A note about the MockWeaver.dll and the ProfileLinker.dll:
These are native assemblies that has specific versions for 32 and 64 bit.
If you are running on 64 bit OS create x86 and x64 directories just like they are in the Isolator installation.
Both MockWeaver.dll and the ProfileLinker.dll needs to be registered via regsvr32.exe.

Googling on Cyclomatic Complexity (CC), gives some interesting results... Among those results, you'll find the two following definitions :

• A measure of the complexity of a software module, equal to e - n + 2, where e is the number of edges in the control flow graph and n is the number of nodes in this graph (that is, the cyclomatic number of the graph plus one)
• A measurement of the intricacy of a program module based on the number of repetitive cycles or loops that are made in the program logic. It is used as a general measure of complexity for software quality control as well as to determine the number of testing procedures
• ...

Those two definitions, though perfectly true, are one of the reason for Sonar to exist: going away from the fact that code source quality is a notion only accessible to elite. Sonar is about democratization of the source code quality concepts to be understandable and usable by every stakeholder in a development project.

Having said that, what is it that CC is trying to represent? This is roughly the number of different paths in your source code and there are two ways in java to begin a new path :

• Calling a method (CC + 1)
• Encountering the following keywords : if, while, repeat, for, &&, ||, catch, case, etc ... (CC + 1)

The good news is that calculating the cyclomatic complexity is a human accessible operation. Moreover, according to the previous definition it's easy to understand that the more paths you have in your application, the more complex your application will be.

But does that mean a program with a high cyclomatic complexity has a poor quality ? For sure not ! Otherwise all developers would prevent themselves from doing anything beyond a simple "HelloWorld" program whose cyclomatic complexity is 1 and would quickly lose their jobs :-)

Having a high total cyclomatic complexity on a program just means that a lot of logic has been implemented in the program but you cannot deduce any quality information from there. When zooming on classes or methods, that's another story.

Is it better to have a method with a CC of 30, or three methods with a CC of 10 each ? If you have been in charge of source code maintenance for an application written by somebody else, you know the answer : when having three methods with a CC of 10 each, the chance is higher that the program is more maintainable, with a better separation of logic. As a consequence, you also decrease the risk to inject a bug. The CC value by method can be used to evaluate the quality of the source code.

At the class level, you can follow the same logic : high CC by class could be the witness of bad levels of decoupling, encapsulation and cohesion.

In fact, what matters in a program is not its total cyclomatic complexity but the fact that each of its methods / classes has a suitable low level of CC.

We'll discuss in an other post how valuable Sonar can be to help identify those non suitable parts of source code.

We are another step closer to 1.0, if you have been watching the mailing lists or the trac timeline you already know that we have had some serious bug fixes over the past couple weeks as well as one new feature.

Bug Fixes:

• Major fixes and updates for the Windmill Unit Tests
• IE fixes for: Drag and Drop, Click, UI usability, Non Compress deps broken
• JS Test Framework bug fixes, JUM assertions, unit tests,
• Improved XPath Generation and bug fixes

Feature

• Full support for launching and killing Google Chrome on Windows (requires Python 2.6)

We really appreciate all the bug reports and emails from you all, thanks for your patience as we try to squash all the bugs.

An additional encouraging note is that we got some great PR this week, which can be found here: Windmill Article in the SDTimes.

Happy testing.

Providing customer support is a top priority for us, be it through our support mailbox, online forums, phone or direct email. We actively try to make our support services available, responsive and of the highest quality. 
So what happened?
However, our efforts hit a road bump in the last couple of weeks, when we had an internal problem with one of our smtp services. This mail service is in charge of relaying mail going out of our support system to our customers, and unknown to us it stopped working. This caused our support emails - including follow up on issues, checking up that problems have been solved and sending patches - did not go out.
Finding out was hardTurns out this can go on for a while before finding out. We were churning along, providing support for the issues that kept coming in, sending out emails to customers and changing the ticket status to 'waiting', all the time oblivious to the problem. Eventually, we had a day where a support case email was cc'd to another team member for follow up, and when he complained he didn't get it we found out about the problem. Upon further investigation the faulty mail service was identified and fixed. It also turned out we had no information about how long we were offline.
Trying to make up for lost timeWe immediately went back to our email archive and looked for the last customer acknoledgement of a support email. This was a couple of weeks in the past so we went ahead and re-sent all the emails we were trying to get out in these weeks. 
So what did we learn?Several things, really. First, that a lull in support cases can be a sign the end of the year is coming and things are slowing down, but it can also be a sign something is not working well. Another thing is that we need to harden our IT systems and get an early indication of a system failure before it impacts our customers. We already set out to implement a self test that will run daily to make sure our support system is working as it should. 
To summarize, I apologize for all of you who didn't get the support you deserve during that time; if you feel we might have missed your case, or if it's otherwise urgent, please write me at doron@typemock.com, and I promise you'll get an answer fast.

• Implemented #636: clearstatcache() after setUp() and before test. [4174]
• Fixed #500: Bump requirement for PEAR package to version 1.7.1. [4198]
• Fixed #612: Bootstrap file is not included before including test files. [4228]
• Fixed #628: Mocked static methods cause fatal errors. [4144]
• Fixed #629: @expectedException does not work with the new namespace separator. [4140]