Lista evenimentelor este urmatoarea:

• Bucuresti - code retreat facilitat de Alexandru Bolboaca
• Timisoara - code retreat facilitat de Flavius Stef
• Cluj Napoca  - code retreat facilitat de Adi Bolboaca. Cu aceeasi ocazie, RABS organizeaza un alt code retreat in Cluj Napoca, ceea ce inseamna ca dezvoltatorii clujeni au de unde alege. Ne bucuram de diversitate, si lucram impreuna cu RABS pentru ca ambele evenimente sa fie la inaltime. Asadar, potentialii participanti sunt rugati sa aleaga unul dintre code retreat-uri, pentru a evita problemele de organizare.
• Sibiu - urmeaza sa fie anuntat.

Last year, after the Agile Lean Europe (ALE) conference, Franck Depierre had the idea to start a Remote Open Space to connect the different communities of practice of Europe, in the spirit of the ALE Network. Franck called this concept xALEc, or The Extreme ALE Club.

Inspired by his initiative we initiate the same concept to unite the AgileWorks Romanian groups: Bucharest, Timisoara, Cluj-Napoca, Iași,  Sibiu, Targu-Mures.

Why

You have some questions and you would like to find answers.

You want to share your ideas to others.

You want to be exposed to new ideas

You want to learn new things.

You can e-meet experienced professionals.

How

Each Tuesday Every two weeks, on Tuesday, we meet at 19:30 (Romanian time) on Google Plus. To attend you need to either open the Google Document and click on the Google Plus Hangout link or you can follow the Twitter tag #awros to see the link to the Google Plus Hangout.

Each attendee makes a short introduction.

We add to this Google Document the topics that we would like to talk about.

We vote the topics we want talk by dot voting on the Google Document.

We chat about the voted topics and we want to keep our ideas on the subject.

After 30 minutes we stop and we draw some conclusions.

We write the conclusions in the google document.

We use Twitter to radiate the ideas we have come up with by using the twitter tag #awros

The first hangout will be on Tuesday 6th of November 2012.

In order to attend

You need an internet connection, and a microphone attached to your computer.

You need a Google Plus account.

30 minutes of your time.

Good ideas.

More information

About Open Space here.

About AgileWorks Romania here.

The code and beer idea is simple enough: we gather in the evening after work, in a pub, have a beer and write some code. It is a social coding event where you can share ideas with other developers. You can come and leave whenever you want.

Why would you come and join us

• meet-up with other programers
• work on your own project
• help others on their projects
• find someone that might help you on a specific topic
• pair with someone and learn new things
• just hang around to talk with people

When

We want to make the first code and beer in Bucharest on 30th of October at 19:00 hours. We will use the Bucharest Agile Meetup Group for registration, here is the event on meetup.

There is no predefined agenda. We just meet-up and work on whatever we feel like it. It will be over... when it will be over.

Laszlo Barabas s-a oferit sa organizeze prima întâlnire, cu scopul de a descoperi persoane interesate de a participa și voluntari pentru organizare. Dacă ești din Târgu-Mureș și te interesează subiectele: Agile, Lean, Software Craftsmanship (și nu numai), te rog să adaugi un comentariu la acest post. Dacă sunt destui oameni interesați, vom organiza cât mai curând prima întâlnire.

Despre AgileWorks: Comunitatea AgileWorks a pornit in 2007 cu scopul de a aduna oamenii interesați de Agile, Lean, Software Craftsmanship și orice altceva ce ajută la dezvoltarea de software de calitate. De atunci, comunitatea a crescut la peste 1000 de membri și este auto-organizată la nivel local în București, Cluj, Timișoara și Iași. Fiecare grup are unul sau mai mulți organizatori locali, aleși pe bază de voluntariat sau dintre cei mai activi din comunitate. Poți consulta istoricul întâlnirilor locale AgileWorks pe grupurile de meetup - vezi link-urile din sidebar dreapta.

Detalii si inregistrare: http://coderetreat.org/events/code-retreat-romania-sibiu

In her first meeting with our local Agile community of practice, Maria will share with us some of her experiences with Agile transformations in various companies.

We'll welcome Maria on Friday, 20.01.2012, 18:30. The location is yet to be established, so suggestions will be highly appreciated!

Va invit sa va inscrieti la unul dintre ele cat mai sunt locuri. Inscrierile se fac folosind grupurile meetup corespunzatoare orasului (vezi sidebar dreapta).

Mai multe detalii despre code retreat sunt disponibile aici.

Evenimentele sunt sponsorizate de:

• Toate: Mosaic Works (tricouri, promovare, organizare)
• Bucuresti: Bit Defender (locatie, masa, after-party)
• Timisoara: ACI Worldwide (masa, after-party), UBIT (locatie)
• Cluj Napoca: Three Pillar Global Inc (locatie), ACI Worldwide (masa, after-party)

Friday, 25.11.2011, 18:30, FITS - Str. Sf. Lazar Nr. 27, Et. II 217

This example will use Spring 3 for the dependency injection, JUnit, Hamcrest and Mockito for testing, but the technologies can vary.

The layers

The typical java web application will havea service layer, on top of a DAL/DAO layer which in turn will calls the persistence layer.

The Service Layer:

View the code on Gist.

The DAL/DAO layer:

View the code on Gist.

Motivation and blurring the lines of the unit test

When unit testing a service, the standard unit is usually the service class, simple as that. The test will mock out the layer underneath - in this case the DAO/DAL layer and verify the interactions on it. Exact same thing for the DAO layer - mocking out the interactions with the database (HibernateTemplate in this example) and verifying the interactions with that.

This is a valid approach, but it leads to brittle tests - adding or removing a layer almost always means rewriting the tests entirely. This happens because the tests rely on the exact structure of the layers, and a change to that means a change to the tests.

To avoid this kind of inflexibility, the scope of the tests will grow from the single service class to all the layers. Now, when testing the service layer, it's not the layer below that will be mocked, but the final layer which is directly interacting with the database - in this case, the HibernateTemplate:

View the code on Gist.

Now the test only focuses on a single responsibility - when creation is triggered, does the creation reach the database?

The last test uses Mockito verification syntax to check that the save method has been called on the hibernate template, capturing the argument in the process so that it can be checked as well. The responsibility of creating the entity is verified via this interaction test, without the need to check any state - the test trusts that the hibernate save logic is working as intended. Of course that needs to be tested as well, but that is another responsibility and another type of test.

Conclusion

This technique invariably leads to more focused tests, which makes them more resilient and flexible to change. The only reason the test should now fail is because the responsibility under test is broken.

Check out the original article on baeldung.