Курс по Test-Driven Development

От край време ми се върти в главата идеята да направя курс по Test-Driven Development. Искам да систематизирам и споделя неща, над които съм разсъждавал и с които съм експериментирал последните няколко години. Съответно, скоро мисля да стане реалност.

Курсът ще е 6-8 събирания в initLab. Искам малка и отдадена група от хора. Ще давам много домашни и ще очаквам всички да ги правят. Мисля да направя по-голям такъв курс в Telerik Academy и този ще служи като бета тест. Искам да навлизам в по-сериозни детайли и по-рошави примери. Съответно, ако още се учите да програмирате, този курс не е подходящ за вас.

Курсът ще включва (без да се ограничава до) следните теми:

  1. Писане на тестове с xUnit. Организация на тестови свити. Добри и лоши автоматизирани тестове.
  2. Unit vs. Integration tests. Тестване в изолация. Тестване в интеграция. Баланс между двете.
  3. Писането на тестове като процес. Ритъм на работа. Continuous testing.
  4. Test-Driven Development. Тестовете като инструмент за дизайн. Interface discovery.
  5. Често срещани проблеми. Бавни тестове. Огромни тестови свити. Трудни за писане тестове.
  6. Behavior-Driven Development и други тестови похвати. RSpec. Cucumber. QuickCheck.
  7. Работа с legacy код. Вкарване на тестове в съществуващи проекти.

Този списък е груб и недодялан, но трябва да ви дава идея в каква дълбочина мисля да навлизам. Със сигурност до началото на курса ще изглежда по-различно.

Ако съм ви грабнал интереса, ето и детайлите:

  • Започваме в началото на февруари (след 4ти).
  • Събиранията вероятно ще бъдат два пъти в седмицата и ще се опитаме да приключим всичко за 3-4 седмици.
  • Сами избирате кой език да ползвате. Моите примери ще бъдат предимно на Ruby, но вероятно ще показвам и други езици. Няма да е нужно да знаете Ruby за да разбирате курса.
  • Ще има домашни. Някои ще бъдат групови. Ще бъде интензивно. Ако не сте готови да му отделите време, по-добре не се захващайте.
  • Няма да е задължително, но ми се иска това да ви струва 50-100лв. Вие си избирате колко, като всичките ще отиват като дарение за initLab. Макар и символична, това е достатъчна сума за да бъдем и аз и вие по-сериозни. Напълно ОК е да не влизате с пари, ако не можете да си го позволите в момента.

Ако имате интерес, пишете ми на stefan точка kanev маймунка гмейл.ком. Планът ми е да събера група и тогава да се уговорим кои дни ще бъдат удобни.

Ако имате въпроси – питайте.

One thought on “Курс по Test-Driven Development

  1. Здравей Стефчо,

    Чудих се под коя точно публикация да напиша коментара си, защото не си писал такава за „скандала в TDD“, върху който си имал няколко публични изяви.

    Днес си четях нещо и попаднах на следното мнение на Мартин:

    I don’t say that there is anything wrong with using test first development approach. If it works fine for you, that is awesome and you should stick with it. What I don’t believe in is TDD as a development methodology or even as the methodology for writing software. Like all methodologies there are advantages and disadvantages and it might be that other methodologies work better for developing the software or having a high quality. TDD puts a too strong emphasis on unit testing in my opinion. I do not believe in unit testing being the key to high quality software. It’s certainly an important aspect but it’s not the only one. Good code should come with unit tests no matter which development methodology is used. We should remember that it is impossible to proof that software does not have bugs. Testing can find bugs but cannot proof that there are no bugs. If one has a large number of tests it means nothing. It could be that it redundantly checks the wrong things. Trusting into unit tests (and methodologies which emphasize unit tests) can be dangerous. One’s code can have a test coverage of 100 % and be developed in a perfect TDD world, but still fails in multi-threading or doesn’t scale. I think there are better methodologies around to write good code. For example having the test being written by a different developer in a black-box way. This is especially important if the developer is doing a systematic error. If he does, he will most likely also introduce the same systematic error in the test code and by that not finding the issue – TDD doesn’t protect against such issues. For that I find code review much more important. TDD is a methodology to fix a social problem. Writing unit tests sucks. It’s a dumb work and most developers are over-qualified for writing stupid and repetitive test code. They don’t want to do it, so they don’t do it. The idea of TDD is to force developers to write the unit test before they write the code. As a goodie the developers get a “you have to think more about your API, so it will be better” and “you see directly whether it works”. But let’s face it: there are other methodologies which can provide the same and writing test code still sucks. Now it sucks even more because you have to adjust your test code whenever you change the code during the implementation There have been in the past other methodologies to fix social problems: they all failed. Especially if something is about metrics. Line of comments per line of code? Good idea till developers start adding // incrementing i by one. You cannot fix the social problems with a methodology. If your developers don’t want to write tests, they won’t. One can easily do TDD and produce non-sense tests if one wants to. Quantity doesn’t matter, quality does. TDD is a methodology ensuring quantity of tests, not quality. There are other methodologies which work better, to ensure quality. I don’t say TDD doesn’t work, certainly it can work quite well in a developer group where everybody believes in it. But if there are developers who don’t believe in it, it can fail. So saying that your software is super-awesome because it’s TDD and another one isn’t is just failing to see that TDD is not the silver bullet (there are no silver bullets in IT). If one has to emphasize that one uses a certain methodology it sounds very much like something is going wrong. One wants to have high quality software, the way to go there, should not matter. It’s like saying one is “agile”. Nice buzzword, but meaningless. TDD cannot guarantee high quality software, so why emphasize on it? TDD certainly has aspects which I find very useful. For example bug fixing is much easier in a TDD setup. But for feature development I think only parts of it should be used and combined with different, better working methodologies.

    На същото място попаднах и на още едно мнение, макар да не идва от superstar:

    And therein lies the problem… I have yet to meet a TDD developer that does not follow this pattern: 1) write test 2) write code that passes test 3) call it done and commit What if the test is wrong or does not actually have coverage? They do not consider the design of their code before writing it. They just shit out the first thing that comes to mind, and if it passes the test, then it must be correct, right? WRONG! TDD developers are like children playing with a multiple choice test that scores each answer along the way and allows infinite changes. They can find what appears to be the right answer (according to the test) but they don’t know why it’s right (or even if it actually is right as that depends on the correctness of the test). To me, TDD means “I can’t architect a properly solution so I’ll write something that passes a test”. I guess it shouldn’t be expected when most of these people were taught in school that all that matters is answerign the test correctly, not understanding why. Since it was mentioned (albeit briefly), “Agile development” to me means “we can’t plan our way out a paper bag”. Quality engineering requires planning, regardless if it’s designing software, hardware, a house, a bridge, or wahtever else. Every form of “agile” development boils down to “plan nothing, shoot from the cuff, and if you miss say that was your intent because you are agile enough to intend to be wrong”. Can you imagine any other engineering discipline using “agile” methods or test driven development? If a mechanical engineer applied TDD to building a bridge, do you think he’d live to see it finished, or be murdered by the families of his testers? P.S. Indenting replies to ease readability makes sense in theory, but indention is not normally done from both sides. You’ve already commited the sin of forcing all page content into an absurdly narrow column without regard to the browser window size. Constraining each reply further is madness!

    Цитататите са от:

    blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/

    В темата се обсъждат наши си неща (линуксарски) несвързани с TDD, но въпроса е повдигнат странично и ще ми е интересно, как би го коментирал.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *