We have an app which is developed in wpf + DevExpress using MVVM pattern. We need to implement Specflow with MStest on viewmodel level.
Have anyone tried this? Any pointers? Is codedUI any good at viewmodel level?
I had two thoughts when I read that question.
First - think if you really need to automate everything through the UI. With an architecture like MVVM you have a great opportunity to hit the application beneath the UI and still get a lot out your test automation. For example write your step definitions against the ViewModels.
Testing against the UI easily run the risk of creating brittle tests. The UI is the part of most application that changes very frequently. Tests hitting the UI need to cope with this somehow (more on this later).
Secondly, for the things that you need to automate against the UI, consider using White which is a nice object oriented abstraction above the UI Automation Library. I've used it extensively and like it.
With any automation be sure to create an abstraction over the actual automation, with the driver pattern for example. A simple way to do this is to create a screen/page object that have properties and methods to interact with the screen/page in question. Your step definitions then uses these wrapper objects.
Keep your step definitions thin and your wrapper objects fat. A bit like a controller in the MVC-pattern. More on this here
I hope this was helpful
Well I haven't tried it but I can't see anything wrong with it. By using specflow you create methods to do one thing say "The user presses the about button" and your code would be something like this
[Given(#"The user presses the about button")]
public void TheUserPressesTheAboutButton()
{
this.UIMap.PressAboutButton();
}
You may have to fiddle around to create all the methods but it's not a big deal. There's a simple guide here. Something that could be a glitch is the naming and identification of the controls so that CUIT builder would be able to find them.
Yes. It works pretty good. The biggest challenge is really defining your sentence structure and Given/When/Then statements so they are consistent and re-usable. Otherwise you end up with Tags and 5-10 givens for a single method. Not really maintainable.
We used Specflow for unit testing MVVM as well as other business components. The Given statements would basically setup the mock data, then execute the test:
Given I have created a database context
And it contains the following Books
|ISBN | Author | Title |
...
I also used specflow for Functional Testing (end to end) for automated testing via TFS. A database and server are deployed (with real or test data), then the functional test suite is executed against that server/database (creating data, modifying data, etc).
Related
I have a requirement to develop a test framework using Cucumber .
Requirements:
There is a Soap WS already developed for an existing project few years ago
There is a new REST ws developed for the same project
I have to validate the responses from the SOAP WS with responses of REST WS and check if both are same or not using a feature file (cucumber)?
basically have to check if fields values in Soap and REST are equal.
how to write the scenario and how to map those fields in SOAP ws with REST ws?
I am very new to BDD and cucumber. elaborate answers are very much appreciated
How to create the scenario
In BDD, we create a scenario with contexts, events and outcomes.
The context is the state in which the scenario starts. So in your case, you have two services, and probably something created in those services that might change the responses. Those become your "Given"s.
Let's say your services are dealing with user details. (Adapt these accordingly for whatever information matters to your scenario.)
Given the REST service has a user 'Chandra Prakash'
And the SOAP service has a user 'Chandra Prakash'
Most of the time in BDD we only have one event happening in each scenario. There can be two events though if there's interaction or something like time passing, and I think this counts too. So we make a call to both services, and the events become your 'When'.
When we ask the REST service for all users with family name 'Prakash'
And we ask the SOAP service for all users with family name 'Prakash'
And the last bit is the outcome, where we look to see if we got the value that's important to us.
Then both services should have found a user 'Chandra Prakash'.
Those lines, together, become the scenario in your feature file.
Rather than just having one scenario to verify that both are the same, I'd look for examples of what the systems do, and use one scenario for each example. But if you want that last call to just check they're both identical, that would be OK.
Wiring up the scenario to automation
Most examples of Cucumber that you find will use something like Selenium to automate over a web page, but you don't have that. Instead of a UI, you have an API. You're coming up with examples of how one system uses another system.
Your automation will be setting up data in the Givens, then calling the REST service or the SOAP service as appropriate in the Whens.
If you work through Cucumber's tutorial, and then use their techniques to wire the scenario up to the two services, you'll get what you're after.
Note that Cucumber has different flavours for different languages, so pick the right flavour for yourself.
Scenarios vs. Acceptance Criteria
In general, I like to ask, "Can you give me an example?" So, can you give me an example of what the REST service and the SOAP service do? If the answer is something of interest to the business and non-technical people, then you can write that example down. Try to use specific details, as I've done here with a user and their name, rather than being generic like
Given the REST service has a user with a particular family name
When we ask the REST service for users with that family name
Then it should retrieve them
This, here, isn't a scenario, even if it's good acceptance criteria. We want our scenarios to be specific and memorable. Try to use realistic data that the business would recognize.
Cucumber vs. plain code
There's one small problem that I can see.
It sounds as if what you're doing might be a technical integration test, rather than an example of the systems' behaviour. If that's the case, and there's no non-technical stakeholder who's interested in the scenario, then Cucumber may be overkill. It's enough to create something in the unit-level framework for your language (so JUnit for Java, etc.). I normally create a little DSL, like this:
GivenThePetshop.IsRunning();
WhenTheAccessories.AreSelected("Rubber bone", "Dog Collar (Large)");
ThenTheBasket.ShouldContain("Rubber bone", 1.50);
ThenTheBasket.ShouldContain("Dog Collar (Large)", 10.00)
ThenTheBasket.ShouldHaveTotal(11.50);
But even that's not needed if you're not reusing the steps anywhere else; you can just put the "Given, When, Then" in comments and call straight to the code.
Here are some arguments I'd use against Cucumber in this instance:
It's harder to refactor plain English than code
It introduces another layer of abstraction, making the code harder to understand
It's another framework for developers to learn
And it takes time to set it up in CI systems etc. too.
If you can't push back, though, using Cucumber won't be the end of the world.
Have some conversations!
The best way to get examples out is to ask someone, "Can you give me an example?" So I'd find the person who knows the business processes best, and ask them.
Please do this even if it's just an integration test, as they'll be able to help you think of other examples in which the systems behave differently. Each of those becomes another scenario.
And there you go! If you do need help that StackOverflow can't provide, there are mailing lists for both BDD and Cucumber, and plenty of examples out there too.
[Pre]
I have to say that I'm dummy newbie who is trying to get together important puzzles with such crucial details as DDD, TDD, MVVM, and EFCore. I have an about 10 years of windows form develop experience in complete wrong manner, and after I'm joined to Plurasight I'm understood that I'm just lost my last 10 years, and this is really sad :).
[Problem description]
I have an App that i want to re-write from scratch by using latest and greatest technics that've learned for the last 6 month on Pluralsight, but the problem is that these new knowledge’s is stopping me, because simply I'm afraid that I'll do it wrong again...(that is stupid I know, but it is what it is).
So back to my questions, I have a big problem domain, and pretty well documented business logic, which i have to turn in to the code. I'm understand that my start point is design data layer, for these purposes I want to use Entity framework core (I saw Julie Lerman's course on Pluralsight and I think's she is amazing and inspires me to use EFCore as ORM for my app). But at the same time leakage of experience produces more questions than what I’ve learned with Pluralsight, and I will try to write them all(please don’t judge me too hard)
It is looks like that I will need 2 or even more data model projects in my solution, and here is why I have multiple document set types, each of the type contain more than one reference books used to generate unique file names and data sheets. But it looks weird to me have 3 Data model projects such as MyApp.PackType1.DataModel, MyApp.PackType2.DataModel, and each of them will be preinstalled with the EFCore, and each of them will generates its own database based on Data Context defined by EF. Isn’t it very redundant or this is correct way?
I don’t understand how to join these multiple Data Models projects, including Shared Kernel into the one nice model
I don’t understand what is the best way to design my data classes? Should they be just POCO’s or I can design them as nice looking classes with the private var’s and public properties? What are the best practices in here?
Also I don’t understand what is the best practice to use a MVVM pattern on top of that, and is it applicable at all to use MVVM in this case?
Should I keep my Tests in separate projects like MyApp.PackType1.DataModel.Tests, or keep them in same project?
Best regards,
Maks!
P.S.
Apologize for unclear definitions and questions, English isn't my native language.
It's very complicated to answer your question because you have asked for a lot of details, but I going to provide a brief answer and I hope it will be helpful.
You can have only one model for your entities (DDD) and create sub model from this model in your end level projects (Web API or UI)
Read point #1
You have to create an Entity Layer project that represents your database and then you can create DTO's for specific scenarios
From my point of view, use Angular but you can use another UI framework such as React or VueJs, but I prefer to use Angular to build UI interfaces and consume .NET Core Web API from client
Create unit tests and integration tests for you Web API projects and as additional feature you can use Db in memory provider for tests
May be this guide is useful: https://www.codeproject.com/Articles/1160586/Entity-Framework-Core-for-Enterprise
Regards
Hm, multiple DbContexts (models) usually come about when you have distinct databases you are using. General rule is one Context = one Database. Exceptions can occur when there are a lot of tables that can be grouped functionally, but there are downsides to that approach.
A DbContext is a repository pattern but for individual tables. Using a Unit of Work pattern and layering with a custom repository provider would allow you to make it "appear" as a single database, hiding the complexity from the front-end.
Your entity descriptions are usually created as straight POCO. You can get creative with different DTOs
In a nutshell, an MVVM pattern goes like this:
Request from UI to a controller
Controller possibly issues multiple calls to Data Layer to gather data
Assemble data in a single ViewModel (everything the page needs)
Return to UI
The beauty of the approach is single roundtrip (request/response) to the UI
Separate Project in my opinion. There are techniques to spoof the database connection using EF so you are not using "live" data.
That CodeProject article will come in handy.
I am building simple REST deployable using Spring Boot. Decided to create it by using failing acceptance test first followed with TDD until its green.
My module is pretty simple, I have 3 API's:
Retrieving list of data from datastore.
Adds item to datastore.
Deletes item from datastore.
I feel like it is good idea to abstract datastore and have maybe backed by Map data structure for testing purposes and use it with either NoSQL or SQL db if I want to for deployments/releases and end to end testing.
On the service layer side I am unsure since it would just delegate call to repository with no logic.
So standard approach would be controller->service->repository. In my case service does not do much(possible some exception handling but not more) and I will end up with interface and implementation as an extra as well as few more lines of code. I fell like going for controller->repository solution in my situation but it is not a practice I have seen and not sure how others would see it.
What's the best way to implement this sort of system?
I feel like it is good idea to abstract datastore
You are right. The abstraction is called 'Repository' in DDD (Domain Driven Design) for example.
On the service layer side I am unsure since it would just delegate call to repository with no logic.
I'm pretty sure there are data that you want to validate. So you should have a layer in the middle (e.g. the domain layer) which will be in charge of this validation.
Even so, if you feel like your application is simple and doesn't require such layers, go without. You will have less supple design, but more simplicity at first. Be careful: while evolving your app, you could run into trouble.
Hope this will help.
This is rather an opinion based question, but if you are asking whether a 3 layer architecture is a must, to that I say no. Be pragmatic, if you don' see a reason for a class/layer/module to exist, it does not need to exist.
A repository has a purpose (to store/retrieve), and the api layer has a purpose, to offer those things through HTTP.
Here is an article for building small services with the sparkframework: https://dzone.com/articles/building-simple-restful-api
I was looking at this example https://github.com/DarthFubuMVC/fubumvc/blob/master/src/FubuMVC.AspNetTesting/Http/can_read_response.cs and wondering how I can integration test fubu mvc.
What I want to do is give it my request or input model, and then all the behaviours and handlers executed, so I am given back just the view model or redirect i.e. I don't need it to render the view.
Suggestions please?
Look at the tests in the integration testing project in FubuMVC instead. If you can get away with it, it's much easier to use the Self Host capability instead. I suppose this could be my weekly blog post for the week.
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);