Although I agree with you alot, this example introduces some problems dealing with multiple enviroments.
What if I want to move my site to a new domain. Do I need to change all my tests? What about dev-enviroment, test-enviroment and production-enviroment?
Defining the base url at the top of the file, or even better, in a config file, would make my life alot easier.
This is a unit test, not a functional test. The logic doesn't change based on the parameters. This code would work in all these environments w/o actually testing it in each environment. Your argument would suggest that to fully test this method you would test it against every domain.
I agree with the concept of not putting a lot of logic in the test but not quite with the example. This makes the test limited to just one instance of the App
One way to look at this example is to say "In an attempt to apply DRY, we broke the test. In a unit test, obviousness is more important than DRY".
I mostly agree, but I think we can do better.
In unit tests, obviousness is more important than DRY, but DRY still matters. Maybe I can refactor my production code to keep things obvious *and* dry. If not, maybe I can factor out a test-only utility, which is itself unit-testable.
What strange advise. This runs completely counter to my experience. Unit tests should be written with the same high maintainability (and therefore Don't Repeat Yourself) requirements as production code. If you don't you end up with buggy, verbose and unmaintainable unit tests that put a drag on the project. I've written a blog post explaining why:
I'm usually the guy on my team that resists the temptation to extract out common test setup, but I would regard your example as just too trivial not to pull up.
I agree with the arguments of having the tests configurable between environments. For me I write all my tests in reference of running it locally, but when deployed on CI, they run against a deployed environment.
But I do agree with reducing the amount of logic in your tests as possible. But where I draw a line is usually at branching instead of simple string concatenation. When you see a 'if' or 'switch' statement, that's when a test starts to smell bad.
I think this is a bad example. If you do not run your test to ensure it's green when written, then you do not need to write a test at all. This "simple" bug would be found instantly after the first test, whats the big deal?
I think a better example would be the use of many if/else statements to handle the differences between a mobile view and a desktop view of the same page within the page object. Vs. using a higher level abstraction level such as abstract factories.
Although I agree with you alot, this example introduces some problems dealing with multiple enviroments.
RispondiEliminaWhat if I want to move my site to a new domain. Do I need to change all my tests? What about dev-enviroment, test-enviroment and production-enviroment?
Defining the base url at the top of the file, or even better, in a config file, would make my life alot easier.
This is a unit test, not a functional test. The logic doesn't change based on the parameters. This code would work in all these environments w/o actually testing it in each environment. Your argument would suggest that to fully test this method you would test it against every domain.
EliminaI like the way article is explained. Simple and crisp!
RispondiEliminaInteresting article!
RispondiEliminaI agree with the concept of not putting a lot of logic in the test but not quite with the example. This makes the test limited to just one instance of the App
RispondiEliminaJumpToUrl(ConstantsConfig.hhtp_protocol + BeanTestHelper.App + "csr." + ConstantsConfig.homepage_url );
protocol - http/https
App- dev,test,stage,prod
homepage - google.ca , google.sg , google.com
"Since such helpers can get quite complex, it's usually a good idea for any nontrivial test utility to have its own tests."
RispondiEliminaLet's test the tests :)
One way to look at this example is to say "In an attempt to apply DRY, we broke the test. In a unit test, obviousness is more important than DRY".
RispondiEliminaI mostly agree, but I think we can do better.
In unit tests, obviousness is more important than DRY, but DRY still matters. Maybe I can refactor my production code to keep things obvious *and* dry. If not, maybe I can factor out a test-only utility, which is itself unit-testable.
What strange advise. This runs completely counter to my experience. Unit tests should be written with the same high maintainability (and therefore Don't Repeat Yourself) requirements as production code. If you don't you end up with buggy, verbose and unmaintainable unit tests that put a drag on the project. I've written a blog post explaining why:
RispondiEliminahttp://andrewtrumper.blogspot.ca/2014/08/complex-logic-in-unit-tests.html
+1
EliminaI'm usually the guy on my team that resists the temptation to extract out common test setup, but I would regard your example as just too trivial not to pull up.
RispondiEliminaI agree with the arguments of having the tests configurable between environments. For me I write all my tests in reference of running it locally, but when deployed on CI, they run against a deployed environment.
RispondiEliminaBut I do agree with reducing the amount of logic in your tests as possible. But where I draw a line is usually at branching instead of simple string concatenation. When you see a 'if' or 'switch' statement, that's when a test starts to smell bad.
I think this is a bad example. If you do not run your test to ensure it's green when written, then you do not need to write a test at all. This "simple" bug would be found instantly after the first test, whats the big deal?
RispondiEliminaagree
EliminaI think a better example would be the use of many if/else statements to handle the differences between a mobile view and a desktop view of the same page within the page object. Vs. using a higher level abstraction level such as abstract factories.
RispondiElimina