Freigeben über

Speaking in ANUG

  • Artikel

Aarhus .NET User Group has been so kind to invite me to come and give a session on June 25th, 2008, and I've elected to speak about TDD and Installers, a subject that regular readers of this blog would correctly surmise is dear to my heart.

Read more about the event here (in Danish, as will be the session itself).

If you are in Århus that day, I hope you will consider coming by and saying hello as well.

Comments

  • Anonymous
    June 14, 2008
    Hi Martin I've been to almost all ANUG's meetings. But without question this is the one I've been looking most forward to. I'm not a TDD believer. I have tried for many years, but I'm not at all convinced that TDD or even writing UnitTests is the right way to develop applications. I know you disagree, and that is why this might be the best ANUG session ever. I do write tests. But its the integration tests that helps me the most. And I almost never use mock objects. I've used mock objects when integrating with external applications/services (e.g. when integrating with a payment provider like the danish DIBS). But to be honest, even here I would prefer real integration tests, if the external system can handle it. I would never mock out the database. Instead I design my database test, so that they are fast and reliable. E.g. I create an empty database (CREATE DATABASE) every time I run a test suite. For every test I Truncate all tables, and inserts enough rows in each table to have a good test setup. I know you don't do this because it is slow. But a quick measure shows me that the first test takes about 1-2 second to create the database and schema. After that it takes > 0.2 seconds per test to truncate the table. So if it is not slow, why would I want to write so much code just to avoid this? By writing intergration test I know that my system works all the way down to the database. And I know that the my data is read and written correct to the database. I'm not a database guy (if you ask me). But my experience tells me that when ever I find an error in my application. It is either on the integration points, or in the UI. Almost never in the Domain. We all know the UI is hard to tests. But the database is very easy to test. So why is it that you want to mock it? When you mock your database, and other integration points, you have to introduce a lot of complexity to your code. Often I see people starting to "program to an interface", use virtual methods etc. This leads to a lot more code you have to write and maintain. It makes it more difficult for new team members. But worst of all, it makes it hard to "change" your application. I'm not talking about refactoring, but I'm talking about "changing" your application. If you have mock objects, interfaces etc. there is so much more code to change, and it will slow you down. Also it requires a lot of discipline, to change the both the System under test and the test themselves, that it gets hard to "Embrace change". Also my experience is that very few people know how to write good Unit Tests. The test I've seen are often very hard to understand. And it is very hard for newbies to learn how to write good tests. I'm not sure where I'm going with all this, except that I would love to hear from a "true believer" why TDD, Mock objects etc. are great. Personally I think that TDD will never become mainstream. So I hope that you will be honest and not just expect everyone to agree that tests are good. : Thomas

  • Anonymous
    June 14, 2008
    The comment has been removed

  • Anonymous
    June 24, 2008
    The comment has been removed

  • Anonymous
    June 24, 2008
    Hi Thomas Thank you for your comment. Being able to run your entire (relevant) test suite in a couple of seconds is what counts. If you can do this against a real database, that's one less reason to being able to replace the data access layer with something else (e.g. a Test Double). There are still other good reasons to do that, but that's beside the point. However, normally, any out-of-process communication (such as a database call) is orders of magnitudes slower than an in-process call, so if test speed becomes a problem, replacing these with in-process Test Doubles is a very effective and common way to increase test speed. I never had problems with compilation time. Could it be that you always compile with Code Analysis switched on? That's going to slow you down a lot. If written poorly, unit tests can make change to the application harder, while the whole purpose was to make it easier. The anti-patterns Overspecified Test and Fragile Test describe this situation in more detail, as well as how to avoid this situation.

  • Anonymous
    June 25, 2008
    Hi Mark. This was a superb presentation, It was one of the best ANUG meetings ever.... I would like to request a copy of the demo if possible?

  • Anonymous
    June 25, 2008
    Hi Brian Thank you, that's good to hear! You are welcome to a copy of the demo code, but to enable me to send it to you, I will need your email address. If you use the Email link almost at the top left on this blog page, I'll get an email where I can reply to you. Not that I mind receiving a gushing comment on my blog as well :)

  • Anonymous
    June 26, 2008
    Hi Mark, I'd like to thank you for taking the time to visit our humble user group and given a great talk. I thoroughly enjoyed the content and the fluent manner in which you delivered it. Hope to see you at another meeting sometime :) /Søren

  • Anonymous
    June 26, 2008
    Hi Søren Thank you for giving me the opportunity to give this talk to a great audience. I'm very impressed at how you have managed to get ANUG up and running on a purely voluntary basis. I look forward to come back another time.

  • Anonymous
    July 06, 2008
    Hi Mark I didn't see you answer before now. Regarding Compile time, we try to keep the number of projects in the solution at a minimum. But it is hard ;-) Regarding Code Analytic... yes it is always turned on. It takes a few extra seconds when compiling, but I rely like the Code Analytics. I'm afraid that we will forget to use it, if it is not turned on. PS: I rely enjoyed you session very much. This was the best prepared talk, I've see in a very long time, and I was very inspired. And you should be more than welcome to come back ;-)

  • Anonymous
    July 06, 2008
    The comment has been removed