Thursday, October 29, 2015

Is it a duck?

Last week, I was so happy. I had a working webclient for pwd! My integration test script allowed me to start a web server (using lighttpd).

Enters Travis CI. This useful tool reminded me that integration tests are not enough. I had broken my unit tests. Not good!

OK, let's fix that. I thought it would be fast. It was not (indeed, it is not over).

I needed to work quite a lot this week. Eiffel allows "expanded classes"; that is, value object classes. That is very useful but almost as easily testable as singletons.

I kept those classes… as simple façades. The release code automatically wires the façade with its underlying implementation. The test code, on the other hand, allows to set a test implementation; in other words, a mock.

Of course, faster said than done. There were two bugs in Liberty Eiffel; I had to fix them.

I also worked a lot on Liberty's mocker tool and library to give it new possibilities.

That done, I began by generating mocks and preparing my scenarii. I also split the tests for better legibility.

The work is still ongoing.

My last words are for Eiffel afficionados, based on my freshest experience.

I had lost the idea that Liberty Eiffel's insert keyword (equivalent to ECMA's ugly inherit {NONE}), brought a whole interface to the class. Not what I wanted.

So, my advice: you should not insert a class if you don’t want to expose its features in your interface. Use an attribute instead. Using export {} is an alternate solution, albeit not pretty because you'd need to also insert ANY to keep valid export clauses for standard features.

If it’s not a duck, it should not quack.

Happy hacking!

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.