Wooow...Internet still surprising me.
(Just skip this post if terms Atari ST + Demo do no ring a bell)
I never imagined I would have the opportunity to listen to this track again : the Union Demo main menu.
mercredi 5 mars 2008
samedi 23 février 2008
"Unit Integrated Tests" for integrator objects
Whether I use interaction based testing or state based testing I usually write "real" unit tests in the sense that only one real object is involved (the SUT, System Under Test) and only stubs and mocks are used for the fixture. It usually is the only way to easily get a good code coverage (or at least to easily specifically cover some parts of the code )
However, Lately, when testing Facade or Adapter objects he seemed to me that the unit tests for these objects were :
- too complicated
- too...useless
For most Facade or Adapter objects :
- They're stateless, so let's forget state based testing, we must use mocks
- They're highly coupled to the contract of the adapted objects (by definition of a Facade or of an Adapter)
This kind of class does nothing clever, they basically chain one or multiples calls. They may have bug though if they do not respect the contracts of the adapted classes.
So a unit test for this kind of class depends more on the contract of the mocked objects, than on the behavior of the class under test. A very clear test smell.
Even worse, the fixtures for the mocks are going to closely mimick the code of the SUT (if a method of a Facade calls an object A and then an object B, the fixture for the test on mocks and stubs will tell the exact same thing).
In this specific case the unit test does not provide an orthogonal view of the behavior implemented by the code (the usual value of a unit test) ; it is the exact same view. If I make a wrong assumption on the contract of the adapted objects, I'm going to make the same exact mistake both in the test and then in the code (TDDly speaking)
The problem basically is that the job of this kind of objects is to integrate other objects in the system. So he seemed to me that it is very hard to try to test an integration behavior in isolation.
That's why, now, when I must deal with objects that heavily depend on the contract of the collaborating objects but do not do anything complicated, "integrator objects", I use integrated tests.
However when I encounter an object that heavily depend on the contract of the collaborating objects and does many complicated things, it just means that it is too hard to test, I refactor.
However, Lately, when testing Facade or Adapter objects he seemed to me that the unit tests for these objects were :
- too complicated
- too...useless
For most Facade or Adapter objects :
- They're stateless, so let's forget state based testing, we must use mocks
- They're highly coupled to the contract of the adapted objects (by definition of a Facade or of an Adapter)
This kind of class does nothing clever, they basically chain one or multiples calls. They may have bug though if they do not respect the contracts of the adapted classes.
So a unit test for this kind of class depends more on the contract of the mocked objects, than on the behavior of the class under test. A very clear test smell.
Even worse, the fixtures for the mocks are going to closely mimick the code of the SUT (if a method of a Facade calls an object A and then an object B, the fixture for the test on mocks and stubs will tell the exact same thing).
In this specific case the unit test does not provide an orthogonal view of the behavior implemented by the code (the usual value of a unit test) ; it is the exact same view. If I make a wrong assumption on the contract of the adapted objects, I'm going to make the same exact mistake both in the test and then in the code (TDDly speaking)
The problem basically is that the job of this kind of objects is to integrate other objects in the system. So he seemed to me that it is very hard to try to test an integration behavior in isolation.
That's why, now, when I must deal with objects that heavily depend on the contract of the collaborating objects but do not do anything complicated, "integrator objects", I use integrated tests.
However when I encounter an object that heavily depend on the contract of the collaborating objects and does many complicated things, it just means that it is too hard to test, I refactor.
dimanche 3 février 2008
TDD : How I was overusing mocks
The path to TDD is hard. When you think that you begin to understand how to apply it, you read this great Jay Fields post, and you understand that you missed the point about stubs...
As explained in his post, I was overusing mocks. I knew that I had to improve a lot in my way of using mocks, but what I really had to do was to use fewer mocks and more stubs. Basically I was missing the point that stubs are still of great use and are not superseded by mocks.
It's been a long time since I learned such an important thing in a post about TDD. Now I'm really going to try to stick to "one assert per test" (including "one mock assert per test")
And trying to do that, I'm also going to try "one test class per test setup". See this presentation about BDD by Dave Astels
As explained in his post, I was overusing mocks. I knew that I had to improve a lot in my way of using mocks, but what I really had to do was to use fewer mocks and more stubs. Basically I was missing the point that stubs are still of great use and are not superseded by mocks.
It's been a long time since I learned such an important thing in a post about TDD. Now I'm really going to try to stick to "one assert per test" (including "one mock assert per test")
And trying to do that, I'm also going to try "one test class per test setup". See this presentation about BDD by Dave Astels
Asus eee and FullerScreen for Firefox
The Asus eee PC is a terrific machine. Now, the screen resolution being what it is you must find ways to use as much as possible the available area in Firefox.
Enters FullerScreen an extension for Firefox. After the install, F11 gives you a real fullscreen (even for a tab)
In full screen mode, you may need the following shorcuts of Firefox :
Enters FullerScreen an extension for Firefox. After the install, F11 gives you a real fullscreen (even for a tab)
In full screen mode, you may need the following shorcuts of Firefox :
- Ctr + T : open tab
- Ctrl + W : close tab
- Ctrl + Tab : next tab (yeah, I know)
- Ctrl + L : go to location dialog
- Ctrl + K : go to search page
vendredi 28 décembre 2007
EasyMock and methods with side effects
I really like EasyMock, but was disappointed to not see any explanation in the documention about how to simulate the modification of an argument of a method with side effects.
I thought that maybe I could write a custom argument matcher that modifies the argument (even if it seems weird to implement a side effect on the matches method of the IArgumentMatcher)
Actually, it was confirmed by this brilliant article about a Generic Custom Argument Matching in EasyMock
I thought that maybe I could write a custom argument matcher that modifies the argument (even if it seems weird to implement a side effect on the matches method of the IArgumentMatcher)
Actually, it was confirmed by this brilliant article about a Generic Custom Argument Matching in EasyMock
mercredi 12 décembre 2007
Continuous Integration and test environment availability
When a developper does not have an environment to run the unit tests of a projet, never allows this team member to check in, even if you have a continuous integration server running.
If the build is broken, this programmer will have to perform several check in with the new code and wait for the next build in order to know if the build was fixed. Et voilà, the continuous integration server has become the test environment for this person...
If the build is broken, this programmer will have to perform several check in with the new code and wait for the next build in order to know if the build was fixed. Et voilà, the continuous integration server has become the test environment for this person...
jeudi 22 novembre 2007
Convert an image to high quality PDF, Redux
In a previous post I explained how to Convert an image to PDF with Gimp, but the quality of the picture in the PDF turned out to be rather poor for printing purpose.
So here is an other way, install tiff2pdf.
On Ubuntu for instance :
Then save your image as a tiff image, then use tiff2pdf to convert it to a PDF. For example, for an A4 sized PDF :
For a multiple pages PDF, preprocess your TIFF files with tiffcp
So here is an other way, install tiff2pdf.
On Ubuntu for instance :
Then save your image as a tiff image, then use tiff2pdf to convert it to a PDF. For example, for an A4 sized PDF :
For a multiple pages PDF, preprocess your TIFF files with tiffcp
Inscription à :
Articles (Atom)