I am sure you have been hearing a lot about containers and Kubernetes. But what are they? For what use? Can they really be used in production or are just a "toy"?
It happens that your can google it to learn more about it. Unfortunately most of the information you will find is quite abstract, or right away too technical, or is more like the slides of a manager of some consulting company that just wants to sell something to someone that just wants to buy something for the company they work for in order to justify a promotion because they will b able to make a nice presentation with some nice buzz words on it.
Scott Hanselman is great on making complex topics understandable. And here is a good example on containers.
terça-feira, 27 de março de 2018
Improving your drawing skills
I always struggle on expressing myself to drawing. Here is the prove :)
However there are people that do it quite nice and easy. I think I will try to lean from them.
quarta-feira, 21 de março de 2018
Are your test cases polluted with object instantiations?
You should consider using the builder pattern with the fluent syntax. A good example from the good google testing blog.
I have used it myself in a C# project and it is really useful as you ensure you build always valid objects, it has a high code reuse, and is very readable.
But of course there are some challenges, like what should be the default values of such objects? It is very difficult to achieve that your tests will not turn red when you modify one of this default values under the hood (or like the British say, under the bonnet :) ).
Even thought the builder pattern is an alternative to the mother pattern at some point you will need some combination of both in order to create some quite different types of objects. Or... can it be that it is a code smell? That if this happens is because the production code is not respecting the single responsibility principle?
Also, in C# you achieve the builder pattern by using extension methods, that of course you will need to implement and maintain.
Nevertheless I highly recommend using this pattern in your tests. I know no better alternative.
Company small = newCompany().setEmployees(2).setBoardMembers(2).build();
|
I have used it myself in a C# project and it is really useful as you ensure you build always valid objects, it has a high code reuse, and is very readable.
But of course there are some challenges, like what should be the default values of such objects? It is very difficult to achieve that your tests will not turn red when you modify one of this default values under the hood (or like the British say, under the bonnet :) ).
Even thought the builder pattern is an alternative to the mother pattern at some point you will need some combination of both in order to create some quite different types of objects. Or... can it be that it is a code smell? That if this happens is because the production code is not respecting the single responsibility principle?
Also, in C# you achieve the builder pattern by using extension methods, that of course you will need to implement and maintain.
Nevertheless I highly recommend using this pattern in your tests. I know no better alternative.
quarta-feira, 14 de março de 2018
Is BDD simply about test automation?
I just found out that at some point in time I was a BDD pervert :)
I was reading a very useful article about the correct usage of BDD. Some anti-patterns are mentioned, and I found out I was falling in at least one of them: "Automation is a side benefit — not the reason to do BDD".
It happens that I was using Specflow, and thinking that just because of that reason I could say I was doing BDD. Wrong! Its clear that achieving a higher quota of automated tests is one of the benefits, but you don't have to automate all your scenarios.
Also the origin of the scenarios was not the best. The scenarios were sometimes scenarios written by the tester, from interpreting the requirements.
There were also some scenarios were coming from the product owner without much interaction with the team.
From the technology point of view, Specflow was sitting on top of our end-to-end testing infrastructure. If it is correct that is another discussion.
BDD is much more than automating tests, it is about conversations between the "three amigos" (business, development, testing). They need to sit together from the beginning. You should go through concrete scenarios. This way you will clarify the expectations everyone has, uncover wrong assumptions, and hunt bugs even before they are born.
I was reading a very useful article about the correct usage of BDD. Some anti-patterns are mentioned, and I found out I was falling in at least one of them: "Automation is a side benefit — not the reason to do BDD".
It happens that I was using Specflow, and thinking that just because of that reason I could say I was doing BDD. Wrong! Its clear that achieving a higher quota of automated tests is one of the benefits, but you don't have to automate all your scenarios.
Also the origin of the scenarios was not the best. The scenarios were sometimes scenarios written by the tester, from interpreting the requirements.
There were also some scenarios were coming from the product owner without much interaction with the team.
From the technology point of view, Specflow was sitting on top of our end-to-end testing infrastructure. If it is correct that is another discussion.
BDD is much more than automating tests, it is about conversations between the "three amigos" (business, development, testing). They need to sit together from the beginning. You should go through concrete scenarios. This way you will clarify the expectations everyone has, uncover wrong assumptions, and hunt bugs even before they are born.
sexta-feira, 9 de março de 2018
Cucumber (Specflow in .net) vs. Robot Framewrok
In a previous blog I mentioned my finding on KDT (Keyword Driven Testing).
A famous framework is Robot Framework. I could avoid seeing its similarities with Specflow, but a little more complicated to integrate as you will my be introducing another programming language to your project. In Robot Framework you will be programming your keywords and functionalities in Python.
Well, I was not the first having this question. I could find a very nice answer to my questions.
Also a comparison.
A famous framework is Robot Framework. I could avoid seeing its similarities with Specflow, but a little more complicated to integrate as you will my be introducing another programming language to your project. In Robot Framework you will be programming your keywords and functionalities in Python.
Well, I was not the first having this question. I could find a very nice answer to my questions.
Also a comparison.
quinta-feira, 8 de março de 2018
KDT (keyword driven testing)
Today I got to know the existence of KDT (keyword driven testing). Again from the Test Project blog. One of the frameworks that allows this in the Robot Framework.
As a previous user of Specflow I am not yet seing much benefit when comparing the two. More the complexity brought by adding a scripting language (Python for example) to define the keywords implementation.
But definitively I will check it further.
As a previous user of Specflow I am not yet seing much benefit when comparing the two. More the complexity brought by adding a scripting language (Python for example) to define the keywords implementation.
But definitively I will check it further.
Is it worth to check "too green" automated tests
Its been quite a while since my last post... Let's try to reactivate this blog!
Just stepped into a test blog recently, Test Project. They have quite some interesting articles there including one about how to test tests. It is a little superficial, but just made me thought about "green tests". If there is a test that since years is being run on the build server, and never failed, is it a smell? Is it a useful test?
First I would say it depends on how the automated testing infrastructure is setup. Let's say the developers must always run a suite of tests on their end (and they actually follow the process, or the tolls make them), then you cannot say that the test is "too green" in the build server, as the possible false assertion never reaches it. But if there is a Gated check in, or tests that are only run on the build server side, then it would be interesting to make some measurements to check when this tests last failed. I will give it a thought :)
Just stepped into a test blog recently, Test Project. They have quite some interesting articles there including one about how to test tests. It is a little superficial, but just made me thought about "green tests". If there is a test that since years is being run on the build server, and never failed, is it a smell? Is it a useful test?
First I would say it depends on how the automated testing infrastructure is setup. Let's say the developers must always run a suite of tests on their end (and they actually follow the process, or the tolls make them), then you cannot say that the test is "too green" in the build server, as the possible false assertion never reaches it. But if there is a Gated check in, or tests that are only run on the build server side, then it would be interesting to make some measurements to check when this tests last failed. I will give it a thought :)
Subscrever:
Mensagens (Atom)