If you could add something to Kentico, what would it be and why?

Use dependency injection (DI) in the API/code to allow for better testability.

It is difficult to test customized code, especially the e-commerce providers, without DI because it requires the testing code to be running the entire site with full database state. It is only possible to test in isolation by creating lots of mocks and stubs which reverse engineering the necessary calls based on what is being tested.

119 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Horizons [Companies] shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

13 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Sean Wright commented  ·   ·  Flag as inappropriate

    Effective testability, which implies decoupling, which can be solved by interfaces, is the real issue here. So merging this with that issue is fine since 'testing' should really be the focus.

    +1 for Gabor

  • Gabor commented  ·   ·  Flag as inappropriate

    if it merges the votes too, that will be fine as far as I'm concerned. The underlying issue is the same. It's impossible to mock Kentico objects, and it would be really useful to have this functionality!

  • AdminMichal Kadák (E-commerce and Platform Product Owner, Kentico) commented  ·   ·  Flag as inappropriate

    Hi,

    we are currently working on improvements in Tests area. I will keep the idea updated. However i am not a fan of ideas that are basically a very specific technical solutions.

    I believe the problem is much better explained here http://ideas.kentico.com/forums/239189-kentico-product-ideas/suggestions/392278-use-dependency-injection-di-in-the-api-code-to-a

    Would you mind if I merge this issue into the other one?

    Regards,

    Michal Kadak
    Platform Product Owner

  • Richard Shackleton commented  ·   ·  Flag as inappropriate

    Agree with Sean on this one. The use of static Context classes causes a lot of tight code-coupling which causes issues with unit tests. Ideally the Contexts would be injected using interfaces which we could then mock in our tests.

    On the point of testing, there is still no ability to call a "SetInfo" method on an InfoProvider when writing a unit test. This also causes issues and requires a layer of abstraction on our side to avoid.

  • Cheryl commented  ·   ·  Flag as inappropriate

    This would be a great addition to Kentico. It is far too difficult to unit test Kentico solutions currently due to everything being implemented as static classes. We would like to implement unit testing and mocking in our solutions using our own tools and preferred methodologies which we're currently unable to do without writing a lot of additional 'wrapping' code to abstract out the Kentico types, which is cumbersome, adds complexity and is incredibly time consuming.

    We would like all objects (TreeNode, SKUInfo etc) and InfoProviders to have interfaces.

    We feel this would be a relatively easy thing for Kentico to implement that would help us achieve our goals much more easily, and would be aligned with industry best practice.

  • Sean Wright commented  ·   ·  Flag as inappropriate

    There is some mocking that is now possible, but the way context data is accessed in Kentico the ability to write unit tests for large portions of the site's functionality is limited.

    Like "Horizons" mentioned, the e-commerce code, while full of features and customization options, has so many instance dependencies and live-site context dependencies that there is no reasonable way to test a scenario like 'Adding an item to a cart that shouldn't have tax applied" and seeing the result of that test as passing because the total tax for the cart is 0.

    Kentico does not rely on interfaces much and developers are required to use a lot of inheritance and accessing static global objects as an API. I understand these are legacy architectural designs but for any sort of testing to be considered a usable feature with Kentico we will need a less coupled design where DI and mock-ability of functionality are available throughout the application.

  • AdminDominik Pinter (Platform Product Owner, Kentico) commented  ·   ·  Flag as inappropriate

    Hi everybody,
    lot of things have been changed in terms of automatic testing. E.g. look at this article: http://devnet.kentico.com/articles/test-automation-possibilities-in-kentico-8

    Can you please let me know whether you are not satisfied with the progress we made so I can close this idea as completed? If not, please explain what you miss the most.

  • Ian commented  ·   ·  Flag as inappropriate

    After our email discussions I can't not give this all 3 of my votes! :)

Feedback and Knowledge Base