I've been working with specflow's scenario outlines where you define your tables as examples below the steps.
I've recently seen tables being used with scenarios as opposed to scenario outlines. Why would you use tables as opposed to scenario outline examples?
What are the benefit of tables? As far as I can see you have a dictionary that has little typesafety when compared to a typed parameter?
I'm sure I'm wrong about this but it seems better to use scenario outlines with tags. I'm sure I'm missing something here.
Scenario Outlines (https://docs.specflow.org/projects/specflow/en/latest/Gherkin/Gherkin-Reference.html#scenario-outline) and Tables (called Data Tables - https://docs.specflow.org/projects/specflow/en/latest/Gherkin/Gherkin-Reference.html#data-tables) are two completely different things.
Scenario Outlines gives you the possibility to parameterize your Scenarios, so that you don't have to duplicate a Scenario a lot of times with only small changes.
Tables are a parameter for your step definitions. This gives you the possibility to pass more parameters to a step definition and in also a more structured way.
Yes, you can access the Table in an non-typesafe way. To get a more typesafe API, you can use the extension methods in the SpecFlow.Assist namespace. You can read more about it at https://docs.specflow.org/projects/specflow/en/latest/Bindings/SpecFlow-Assist-Helpers.html
Related
Does anyone know if there is a definitive best practices guide for GORM? I find information scattered across different blogs and different resources, but I can't find a definitive guide. I find stuff that says to not do database related stuff in controllers and to keep those things in the service layer, for example. However, it'd just be nice to se what the suggested approach for writing a simple web app is. Should we always use command objects in controllers and pass those command objects to services? Should we store those command objects in session rather than storing actual domain objects in session, which seems to cause a lot of lazy init exceptions, etc.?
I've tried to piece together the information that I've found, but if anyone knows of a comprehensive resource, that would be great.
There is some great information available from the GORM Gotchas series. It's in three parts.
GORM Gotchas (Part 1)
GORM Gotchas (Part 2)
GORM Gotchas (Part 3)
To answer your specific questions about Services and Command objects.
Q: "Should we always use command objects and Services?"
A: Some would argue that it's overkill to do so, however I personally think it's a great pattern and makes things much easier to test and extend. It may seem like a lot of effort but it does pay off in large projects.
Q: "Should we store command objects in session rather than domain objects?"
A: Store as little in the session as possible (if at all). If you have to store something there it's best that it be small and light weight. Command objects (typically) are going to be better for this than a Domain class.
Update (11/19/2014)
I'd like to highlight a very good series that outlines a lot of the potential issues faced using GORM and Hibernate. It's very long, but worth reading if you plan on using GORM/Hibernate in a large scale multi-user project. Don't be turned away by the negative approach because it does contain a lot of useful information.
I don't like Hibernate (and Grails), PART 1
I don't like Hibernate/Grails, part 2, repeatable finder problem: trust in nothing!
I don't like Grails/Hibernate part 3. DuplicateKeyException: Catch it if you can.
I don't like Grails/Hibernate, part 4. Hibernate proxy objects.
I don't like Hibernate/Grails part 5: auto-saving and auto-flushing
I don't like Hibernate/Grails part 6, how to save objects using refresh()
I don't like Hibernate/Grails part 7: working on more complex project
I don't like Hibernate/Grails, part 8, but some like Hibernate and Grails. Why?
I don't like Hibernate/Grails part 9: Testable code
I don't like Hibernate/Grails part 10: Repeatable finder, lessons learned
I don't like Hibernate/Grails part 11. Final thoughts.
The book Grails in Action talks a lot about best practices in Grails. At the time of this writing it isn't published in its final form, but you can buy and read the preview.
I was recently looking for the same answers you are asking and that book has helped me a lot.
I'm working on a Ruby on Rails project. The project has a main database table, called 'Post'.
This table is used for storing questions, answers, comments and announcements as different post types. Currently we use only one model to access the data. But while working on the systems it feels cluttered. Because every post type has some differences.
What is a best practice:
Split the post resource into different resources, but using only the one Post table for data access?
Split the database table into comments, questions, answers and announcements tables; and use resources for each table (model+controller+views)?
Short answer: it depends.
What you're doing now is pretty close to Single Table Inheritance (STI), though it sounds like you're using a single Post class which contains all your different behaviors. STI is a valid approach to storing your model data, but like everything, it has advantages and disadvantages.
My recommendation would be to use separate classes to encapsulate the behavior of separate domain models. This is the fundamental paradigm in OOP, so I would say it's probably a best practice.
Assuming you split your behavior across classes, the question of whether you use a single table to store them or multiple tables really depends on the complexity of your queries and how many common fields there are across your models. If they share a lot of common fields, STI may work nicely. If not, you're probably not going to enjoy the overhead of all the extra reads/writes you'll pay. But all that is really secondary and can be figured out as your app grows and you learn more about the usage patterns.
Try it using STI and see how it goes. Splitting things up into multiple tables is easier than the opposite, so a migration path is not necessarily too hard.
I think the choise should be based on every certain situation. Just enumerate advantages and disadvantages of each option for you. Points to investigate and make decision could be like: number of differences between each type of entities, the way to access entities, frequency of usage of each type of entities, maintability of code, forecast of changes in the future, and many others.
I've got this medium-sized app that is starting to get too complex. I'm considering splitting it in two. But I'm uncertain about how would I share information between those.
I've been able to make two big groups of models; One group deals with "pictures" and the other one deals with "sales data".
Some utility models, such as the authentication/authorization related ones, will have to be copied over, I guess. But let's concentrate on the two Big Groups.
The two data sets are maintanied by different people, so they would split quite naturally.
The only place the two groups "overlap" are a couple reports, that pull data from both "pictures" and "sales data". The information in both cases resembles an array of hashes, with different depths, pointing to calculus (around 60 numbers per system).
That's pretty much the only thing holding the split; I'm not sure about what would be the best way to share information between both apps.
I'd appreciate any pointers to what would be the best way to accomplish this. Should I try to use the same database for both apps? Should I use some kind of web service instead?
The simple solution would be getting both the applications to use the same database. The problem of doing so would be that you'd get some code duplication on the models on the overlap. You could of course fix it with a git submodule or custom gem... An interesting to look into regarding this would be rails engines.
A different solution would be that 1 application has the data and expose an RESTful API and the other pulls from it. But then you need to decide which one gets to "manage" the reports.
It's a pretty complex decision and I can't help you make it without all the data, but I hope this has been helpful ^^
Also, duplicating the code will create caching problems, concurrency problems.
I was wondering what the "correct"-way is when using a Linq to Sql-model in Visual Studio.
Should I create a new model for each of my components, say Blog, Users, News and so on and have all different xxxDataContext's with tables and SPROCs added in each of these.
Or should I create one MyDbDataContext and always work against that?
What's the pro's/con's? My gut tells me to divide it up in smaller context's, but it also feels like that could bring problems as the project expands?
What's the deal? Help me Stackoverflow :)
There will always be overhead when creating the data context as the model needs to be built. Depending on the number of tables in your database this might not be much of a big deal though. If it's only 10 tables or so, the overhead will not be much more than that for a context with say 1 table (sorry, I don't have actual stress testing to show the overhead, but, hey, maybe that gives me something to blog on this weekend).. When looking at large databases the overhead might be a enough to consider using seperate contexts.
The main advantage I would see with using a single data context is that you gain the ability to use JOINs in your LINQ query and that will be translated to T-SQL. Where as if you do the join after the arrays of objects are pulled, the performance might be a bit slower. Additionally, keeping track of multiple data contexts might be confusing and good naming conventions would be needed. So building your own data model w/ business logic which encapsulates the contexts would be a bit harder. I've done this and it's not fun :)
However, if you still feel you want to go that route, then I would recommend putting similar tables (that you might need to join) in the same context. Also, there are some tuts online that recommend using a shared MappingSource when using multiple contexts that use the same source. Information on this can be found here: http://www.albahari.com/nutshell/speedinguplinqtosql.aspx
Sorry, I know that's not really a black and white answer, but hopefully it helps :)
Addition:
Just wanted to add that I did a small test and ran 20,000 SELECT statements against a small sized table using 2 different data contexts:
DataClasses1DataContext contained mappings to all tables in the db (4 total)
DataClasses2DataContext contained a single mapping for just the one table
Results:
Time to execute 20000 SELECTs using DataClasses1DataContext: 00:00:10.4843750
Time to execute 20000 SELECTs using DataClasses2DataContext: 00:00:10.4218750
As you can see, it's not much of a difference.
I learned some time ago about Decision Trees and Decision tables. I feel that Decision Tables can help with conditional If-Then-Else statements. In particular, I feel that Decision Tables have no side-effects, for example, if you didn't notice that you need one more "else if" statement.
But I am not sure how I can implement it. Arrays? Database Tables?
Does anyone even use Decision Tables in their code, nowadays?
I would highly recommend chapter 18 of Code Complete.
You could also check this post What Are Table Driven Methods
Well, I did my own research :S
This is something from IBM about decision tables used to make testing scenarios
This is from a company that makes decision tables that are then translated to if-then-else statements in vb.net.
Open source ruby workflow and bpm engine that uses decision tables.
So, I am still looking. If anyone has some good answers, please enter them in.
Multi-platform, CCIDE-0.5.0-6 (or later) is available at SourceForge and Github.
See the web page at http://twysf.users.sourceforge.net/
A table-driven method uses data structures instead of if-then statements to drive program logic. For example, if you are processing two types of records (tv versus cable) you might do this:
hash[tv] = processTvRecords
hash[cable] = processCableRecords
In some languages, like Ruby or Perl, this technique is straightforward. In Java, you'd need to use Reflection to find method handles.
If you want to learn about decision tables, investiagethe Fitnesse testing framework at http://fitnesse.org/.
By far the best implementation I've seen for decision tables is an application called Prologa, which is available for download at http://www.econ.kuleuven.be/prologa. Unfortunately, it's only available in Windows, and there can be a short delay while you wait for the evaluation key.
The software handles conditions that are non-binary, can collapse similar rules, and actually tracks the number of combinations that your table currently covers so it's great for completeness checks for particularly large tables. Also handles nested tables gracefully (where the result of one table can be the condition of another table).