I have started to use Selenium + BDD Cucumber and I find these two technologies working quite nicely together. I am a bit concerned regarding the approach to what can be improved much more if Cucumber was offering BeforeAll and AfterAll annotations to achieve faster verification on specific areas with a more granularity. Say for example I wanted to write this scenario (I am being generic on purpose just to show my point)
Scenario Outline: The customer can update their details
Given I am logged in the platform
And I navigate to my details page
When I update "field" in my details
And Save
I should see the "field" updated
Example:
|field |
|name |
|surname |
|address |
Being a scenario outline that means it's going to be executed 3 times as 3 separate scenarios. The problem I see here is that every time the scenario will start from scratch, giving you the delay of logging in every time (or in general to perform all the actions to get you to the point you want to be).
One can use #Before but doesn't change much because these actions will be executed anyways every time (and also I am not entirely sure that is the right way of doing things in BDD).
Some people are suggesting to alternate the checks for each field in a series of When/Then that seems to be against the BDD basic principles. Also in this specific case it means that the 3 scenarios will be compacted in one and if the customer fails to update the name field, the others will not be executed giving me a pass rate of 0% whilst it could be 66% (assuming for simplicity we only have 1 scenario and the other two fields are successfully updated). Moreover if updating name has a bug as well as updating address I will only be aware of the problem in the first one and understand about the other only when the "updating name" steps succeeds.
A BeforeAll would probably solve the problem but it's not available in Cucumber.
What I would like to achieve is to perform a series of steps to get to as specific page and then perform tests per field (or with a different level of granularity) and execute all of them in a "when I do this, then I should see that..." fashion so that if anything fails I know what fails and what passes but at least I am sure everything has been covered and not skipped because previous steps have failed.
Apologies for the long post but I was hoping to explain my view as best as possible. Not sure if it's clear or makes sense at all.
Thanks for your replies
Limiting this to one scenario per field is being too rigid for BDD. I like to think of a scenario as a distinct behavior coupled to an assertion that ensures the behavior is functioning. It would be appropriate to test that all the fields are being updated, unless a group of fields can be isolated as a separate behavior, for instance changing your email should send a verification. That should be a separate scenario from the fact the email field gets updated.
This is where data tables become nice to use. Specify a data table for the fields you want to update so you can specify multiple fields in a single scenario. You can use a data table in your assertion in order to compare multiple fields at once.
Scenario: The customer can update their details
Given I am logged in the platform
And I navigate to my details page
When I update my details with:
| Field | Value |
| Name | Bob |
| Surname | Jr |
| Address | 123 Smith St |
And Save
Then my details should be:
| Field | Value |
| Name | Bob |
| Surname | Jr |
| Address | 123 Smith St |
Related
What do you advice to where to store computed values? Example: API serves to me product property as union of 1 | 2 | 3. In app this is interpreted as normal | premium | platinum. When user changes this, to API goes as 1 | 2 | 3. What is the most reliable way to store? As original API values (and use selectors or similar and compute) or values which I use on front?
You are displaying normal | premium | platinum as a visual representation of the actual numeric API values. Since you will need the numeric values again, translating them back and forth bears the risk of values of introducing errors, e.g. when a new state is added by another developer.
My recommendation is: Internally work with the numeric values. If it comes to showing them to the user, use a selector like selectNameForProduct that will give you the strings. Then you have only one place where you need to deal with an maintain the strings.
I have the following problem, we have some .net Web API's which i want to monitor.
So lets say i have one basic API which has one Method with the following options:
/api/appliances/list
/api/appliances/list/userid
/api/appliances/list/userid/appliancecategory
In fact i have some more operations, but this is not really important,
So i want a query which gets the average response type per operation
I am able to select it with a regex like this:
requests
| where name matches regex "^GET \\/api\\/appliances\\/categories\\/[\\w]+$"
Does someone have an idea how to accomplish this
Maybe you should add | project name, xxx to end of the query.
A similar issue can be found here.
Is there any way to store a pre test score in SCORM 2004. I have developed a module in actionscript 2. The pre test and post test uses the same question set.
The client is now demanding that the pre test scores should also be stored along with post test. Is there any way it can be done. Which value should / can I set for this.
I have spent last two days trying to find a solution to this. Is there any way to set a custom variable? or is there any pre set variable name that I missed?
It sounds like you're trying to put the pre-test and the post-test in the same SCO. The cleanest way to report separate pre and post test results would be to put the pre and post tests in their own SCO, by editing your packages imsmanifest.xml file. (see more on content packaging here: http://scorm.com/scorm-explained/technical-scorm/content-packaging/) You can link back to the same content multiple times in the same manifest and include query string parameters which your content then reads and uses to know what mode it's in (pre-test vs post test).
That said, a lot of people avoid using multiple SCOs so they don't have to think about how their LMS or SCORM manages those SCOs. Using only a single SCO gives your content a lot of control, but the trade off is it looks like one monolithic item to the LMS, so reporting on multiple tests can't be as nice. So, there is no specific pre-test variable because SCORM is designed on the assumption that pre-tests would go in their own SCO, so there is no need for such a variable.
What you can do in a single SCO is create additional named objectives and interactions. If you just want the score for the pre-test, that's going to look better, but if you're tracking responses to each question you'll wind up with a list of items like "PreTest question 1, PreTest question 2" ... and continuing to "PostTest question 1, PostTest question 2"... the naming scheme is up to you of course, but the constraint is that you're dealing with one list of objectives and interactions and can only differentiate them by name.
An example course using objectives and interactions: http://scorm.com/scorm-explained/technical-scorm/golf-examples/#advancedruntime
Some tips on what tests should report (and how): http://scorm.com/blog/2010/11/4-things-every-scorm-test-should-do-when-reporting-interactions/
Sorry for not being more step-by-step, but as you can see you have a couple of options, each of which involve a little more detail than I can really put in one answer.
While you didn't describe the structure of your course, I'll respond based upon the possibilities. I am assuming you have a pretest, content and a posttest:
You have one large SCO, which contains the pretest/content and SCO:
If you need the info only for your course to use and display within the course:
You can save the pretest and posttest scores in the cmi.suspend_data. Most people store this information in name/value pairs up to 64K chars. with the SetValue command you can
rtn = your_api.SetValue('cmi.suspend_data','pretest=69,'+oldSuspendData)
Again, you would only use this if your course needed to display this information within the course only and take action on it based upon the pretest results. Obviously, you should code to make sure you get clean data back and handle any odd conditions, like no data. If however, the client wants the data in the LMS and visible to the LMS admins, you'd need to look at the option below
If you need the LMS admins to have access to the pretest/post test scores:
you'll really need to separate each sco (pretest,content,posttest) but you won't be able to communicate (through SCORM) those scores between each SCO. ie: post test won't know what the pretest score is. You can look at nice examples of how to separate your content into SCOs from the url below. You can easily share the pre and posttest HTML/SWF but pass a querystring to the HTML or use the in the manifest to tell your code what it is. From my experience, there are some LMS which will not pass the querystring and therefore should use both.
Simple MultiSCO: http://scorm.com/wp-content/assets/golf_examples/PIFS/ContentPackagingOneFilePerSCO_SCORM20043rdEdition.zip
If you need to know the pretest score AND have the info sent to the LMS like a SCO
SCORM offers no way to get around this issue in SCORM 2004. I would first tell them the complications. If they still need this hybrid solution, I would us ajax to securely communicate the learnerID, courseID (if any), SCOID (pretest/content/posttest) and score to a server where it can be retrieved. Cookies are a no-no because they assume you'll be on the same machine between SCOs. Additionally, if there is the possibility of xAPI, you could do this much easier.
I come from a SQL background so I've been having a problem designing my NoSQL firebase schema. I'm used to being able to query for anything using the "WHERE" clause, and it seems more difficult to do so in firebase (although the performance EASILY makes up for it!).
I'm storing "track" objects for songs. These objects have key/value pairs such as artist_name, track title, genre, rating, created_date, etc. as below:
tracks
|_____-JPl1zwOzjqoM8xDTFll
|____ artist: "Bob"
|____ title: "so long"
|____ genre: "pop"
|____ rating: 52
|____ created: 1403129692781
|
|_____ -JPv7KnVi8ASQJjRDpvh
|____ artist: "Mary"
|____ title: "im alright now"
|____ genre: "rock"
|____ rating: 70
|____ created: 1403129692787
The default behaviour on my site will be to list all these tracks, with the newest added track appearing at the top of the list. I can set my $priority to be created and just turn it negative (created * -1) to achieve this effect I believe.
But in the future, I'd like to be able to filter/query the list by other means, for example:
Retrieve all tracks that have a genre of rock, pop, or hip-hop.
Retrieve all tracks that have a rating of 80 or higher, and have been added in the last 7 days.
How is it possible to achieve this in firebase? My understanding is that there are really only 2 ways to order data:
Through the "ID" value, which has the physical location of "firebaseURL.firebaseio.com/tracks/id", which in my case, was automatically selected for me when I add a track. This is okay (I think) as I have pages for individual track pages that list details, and the URL on my site is something like "www.mysite.com/tracks/-JPl1zwOzjqoM8xDTFll".
By using a $priority, which in my case, I've used on the "created" value so as to order my list in proper date order.
Given the way I have things set up (and please do let me know if there's a better way), is there a way I can easily query for specific genres, or specific ratings?
I read the blog "Denormalizing your Data is Normal" (https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html), and I think I understand it. From what Anant describes, one way to achieve what I want would maybe be to create a new object in firebase for a genre and list all the tracks there, like so:
tracks
|______ All
|_____ -JPlB34tJfAJT0rFT0qI
|_____ -JPlB32222222222T0qI
|_____ -JPlB34wefwefFT0qI
|______ Rock
|_____ -JPlB32222222222T0qI
|_____ -JPlB34tJfAJT0rFT0qI
|______ Pop
|_____ -JPlB34wefwefFT0qI
The premise in the blog, was that hard drive space was cheap, but a user's time is not. Thus, it's okay for there to be duplicate data as it allows for faster reads.
That makes sense, and I wouldn't mind this method. But this would work only if a user wanted to select all tracks from only ONE genre. What if they wanted to get all the tracks from BOTH rock AND pop? Would I have to store another object called Rock&Pop and store a track in there each time someone submits a song of either genre?
genre
|_______pop-rock
|_________ -JPlB34tJfAJT0rFT0qI (a rock song)
|_________ -JPlB34wefwefFT0qI (a pop song)
|_________ -JPlB32222222222T0qI (a rock song)
Also, would it make more sense to store the ENTIRE track object or just a reference using the trackid? So for example, under /genre/pop:
Should I store just the reference?
genre
|______ pop
|______ -JPlB34wefwefFT0qI
Or, Should I store the entire track?
genre
|______ pop
|______ -JPlB34wefwefFT0qI
|___ artist: "bob"
|___ title: "hello"
|___ genre: pop
|___ etc..
Is there a performance difference between the two methods? I'm thinking that maybe the latter one would be faster, as I wouldn't need to query for each individual track for the other details but I just want to be sure.
I've redone my firebase schema several times already. I've made some improvements, but as my application is getting bigger, changing it gets more costly and consumes more time. It'd be nice if I could get these questions cleared up for the final time before I spend a lot of time redoing the rest of my code to match it again..
Thanks for any help with this, it's very much appreciated. And please let me know if you need additional information.
Firebase is rolling out a lot of additions to the query API over the next year. Contextual searching (where foo like bar) is probably never going to be a big hit in real-time data--it's slow and cumbersome.
There is a two-part blog article on sql queries and equivalent patterns in Firebase. I'd recommend you give it a read-through. Part 2, in particular, talks about Flashlight.
Why ElasticSearch and a service? Like real-time data storage and synchronization, search is a complex topic with a lot of boilerplate and discoverable complexity. It's easy to write a where clause in SQL and that will get you a ways, but it quickly falls short of user expectations.
ES can be integrated with Firebase in a snap (the Flashlight service took less than 5 minutes to integrate with an app, last time I attempted it), and provides robust and thorough search capabilities.
So until Firebase rolls out some game-changing features around querying, I'd suggest checking out this approach at the start, rather than trying to bolt on search capabilities by another means.
In your examples above, you build different hierarchies and store a little bit of the data, but just put the IDs in as keys. So when you get that onto the client, you'll probably still end up sorting by some of the data fields.
I like to let Firebase handle the sorting for me by using multi-part keys.
For instance, if I needed to access tracks by genre and artist name, I'd make a flat index node called tracksByGenreAndArtist, with a key composed of genre_name + artist_name + track_name + track_id. The value would be an object with artist name, artist id, track name, and track id. Adding the id is just to ensure it will be unique.
Now all the data is accessible in order of genre, artist, and track name. You could even do a predictive search against it, it's so fast.
Assume the user has selected the genre "Rock", and she types a 'B' into the search box. You could populate the predictions dropdown by grabbing the first ten tracks by artists whose name starts with 'B':
indexRef.orderByKey().startAt('Rock'+'B').limitToFirst(10);
Use the partial data object you've stored at that location to show the name of the artist and the track in the dropdown.
If the user selects a prediction, then use the track id to retrieve the full track object from your tracks node and artist id to retrieve the full artist object from the artists node.
If the user types a different letter, then just toss your predictions and do another predictive fetch, e.g.,
indexRef.orderByKey().startAt('Rock'+'Br').limitToFirst(10);
Also, to your question of what to do if you needed to search both Rock and Pop genres? Well, you can do two queries like the ones above pretty quickly
indexRef.orderByKey().startAt('Rock'+'Br').limitToFirst(10);
indexRef.orderByKey().startAt('Pop'+'Br').limitToFirst(10);
You could group them separately in your predictive dropdown: The first ten from Rock, followed by the first ten from pop. If that isn't perfomant enough for you, you could always make a lot of combinatorial indexes with the same tiny data objects and every unique combination of genre that could be selected as a search filter, I suppose. Still, that "disk is cheap but the user's time isn't" is your guiding maxim here.
I know this question has been asked so many times before but I couldn't find the exact answer for mine. So please let me ask it here.
We built a CMS to control one site. Now the company is expanding and we have a couple more sites with almost identical core structure. We decided to go with one database for easy maintenance later on.
We have about 10 tables. For example, Pages, News, Settings (different for each site), ...
It doesn't sound like a good idea if we add one App_ID (or Site_ID) column to every each of these tables so we know what records from which particular site we should pull out.
For instance,
PAGES:
PageID | Body | SiteID
1 | abc | 1
2 | cde | 1
3 | aafd | 2
4 | gsgs | 2
5 | feg | 3
I think it is very abundant to add this SiteID Column to every table in this Database.
I looked carefully at the Multi-Tenant Architecture but I don't know how to apply it to our sites CMS.
What is the best way to handle this situation, please help. Any enlightenment is appreciated.
Simple Code
We've recently been reviewing various strategies for multi-tenant single database.
If you don't want to add a Site identifier to your tables then you could give each tenant their own schema and set of tables. Each tenant could have their own connection string which only provides access to their schema (you would obviously need to switch connection at runtime (easy enough with both EF and NH if you are using these).
However, the option we opted for was to introduce an additional level into our application such that each component of the application (in your case News, Pages etc.) was represented as a feature in the database.
Each site then has a collection of feature "instances" and the data stored for each of those features (a blog might have posts, tags, categories) has a reference to the feature instance (not the site).
This does add additional complexity but we have found it to be extremely flexible and decouples our feature data from the site (make it possible to move feature instances between sites if we wanted to).
Mixed answer. Work in a similar project, same database structure, several sites.
We tried several stuff.
We are fan of "best practices", "database normalization", "design patterns", but, we ended using a practical approach, more than theorical.
We had one or more databases for each site / company, and each database table had a "site_id", and it worked.
We had some cases where a single company decided to split their database site for each division, so one database become several databases sometimes within the same database server, sometimes different database server.
We had a case where a company with a single site, buy a smaller company, added a new site with same database structure, and after 5 yeas, they merge the data.
The several sites plus "site_id", worked well.
Multiple databases would be the recommended way since it allows simpler backup and restoration of a single site. Also, if you find you need to introduce replication slaves, replication can be more efficient with the use of separate databases. Most multi-site hosting solutions I know of, use multiple databases.
However, if you are intent on a single database, the other option is to duplicate the tables with a prefix indicating which site it belongs to.