I would like to execute extra actions after a successful fork .
(e.g. automate the creation of a CruiseControl.net project).
Which code should I modify? Where should I start from?
There are many options to implement that, according to the source code.
the first option should be: modify app_services/projects/fork_service.rb
another option could be: implement a project_service (e.g. model, worker), which will be binded to an external (unexisting) API which will manage the complexity of the project creation
(more links when my reputation will be high enough ;-))
Related
I am automating acceptance tests defined in a specification written in Gherkin using Elixir. One way to do this is an ExUnit addon called Cabbage.
Now ExUnit seems to provide a setup hook which runs before any single test and a setup_all hook, which runs before the whole suite.
Now when I try to isolate my Gherkin scenarios by resetting the persistence within the setup hook, it seems that the persistence is purged before each step definition is executed. But one scenario in Gherkin almost always needs multiple steps which build up the test environment and execute the test in a fixed order.
The other option, the setup_all hook, on the other hand, resets the persistence once per feature file. But a feature file in Gherkin almost always includes multiple scenarios, which should ideally be fully isolated from each other.
So the aforementioned hooks seem to allow me to isolate single steps (which I consider pointless) and whole feature files (which is far from optimal).
Is there any way to isolate each scenario instead?
First of all, there are alternatives, for example: whitebread.
If all your features, needs some similar initial step, maybe background steps are something to look into. Sadly those changes were mixed in a much larger rewrite of the library that newer got merged into. There is another PR which also is mixed in with other functionality and currently is waiting on companion library update. So currently that doesn't work.
Haven't tested how the library is behaving with setup hooks, but setup_all should work fine.
There is such a thing as tags. Which I think haven't yet been published with the new release, but is in master. They work with callback tag. You can look closer at the example in tests.
There currently is a little bit of mess. I don't have as much time for this library as I would like to.
Hope this helps you a little bit :)
I'm new to cucumber as a testing suite. I notice that as I build out feature and write steps. Lets say as a bad example (since I'm working backwards) I write a bunch of stuff for creating posts that require a User.
I end up writing a bunch of User based steps (log in process etc) in a feature set mainly dedicated to Post features.
Is it best practice to later move steps into the appropriate feature set as tests get more complicated and features get added?
You have two parts to consider here.
Organize scenarios so they make sense. That is to place them in the proper feature files.
Organize the implementation of the steps so they make sense. That is, implement the steps in the proper source code files.
Your question boils down to "What makes sense in my context?".
It depends on your stakeholders, do they want all user facing scenarios in the same feature file or are they more interested in business facing scenarios that sometimes involve users? Organize the scenarios so your stakeholders are happy.
How should you organize the steps then? It depends on your developers and your ability to share state between step definitions that are implemented in different source code files.
My approach would probably be to start out small and let the suite grow. This would initially not involve sharing state between different classes during runtime. When the suite feels to large to handle, divide it in two parts that are as coherent as you can make them. When this gets to large, repeat the division again. You will, hopefully, end up with something that works well in your context.
Remember that your context and your product is unique. It probably deserves a unique solution that your team feel they can maintain.
Understandability and therefore manintainability is the most important property I can think of regarding the executable specification you are building.
I am working on a BDD web development and testing project with other team members.
On top we write feature files in gherkin and run cucumber to generate step functions. At bottom we write Selenium page models and action libraries scripts. The rest is just fill in the step functions with Selenium script and finally run cucumber cases.
Sounds simple enough.
The problem comes starting when we write feature files.
Problem 1: Our client's requirement keeps changing every week as the project proceed, in terms of removing old ones and adding new ones.
Problem 2: On top of that, for some features, detailed steps keep changing too.
The problem gets really bad if we try to generate updated step functions based on updated feature file every day. There are quite some housecleaning to do to keep step functions and feature files in sync.
To deal with problem 2, I remembered that one basic rule in writing gherkin feature file is to use business domain language as much as possible. So I tried to persuade the BA to write the feature file a little more vague, and do not include too many UI specific steps in it, so that we need not to modify feature files/step functions often. But she hesitate 'cause the client's requirement document include details and she just try to follow.
To deal with problem 1, I have no solution.
So my question is:
Is there a good way to write feature file so that it's less impacted by client's requirement change? Can we write it vague to omit some details that may change (this way at least we can stabilize the step function prototype), and if so, how far can we go?
When is a good time to generate the step definitions and filling in the content? From the beginning, or wait until the features stabilize a little? How often should we do it if the feature keep changing? And is there a convenient way to clean the outdated step functions?
Any thoughts are appreciated.
Thanks,
If your client has specific UI requirements for which you are contracted to provide automated tests, then you ought to be writing those using actual test automation tools. Cucumber is not a test automation tool. If you attempt to use it as such, you are simply causing yourself a lot of pain for naught.
If, however, you are only contracted to validate that your application complies with the business rules provided by your client, during frequent and focused discovery sessions with them, then Cucumber may be able to help you.
In either case, you are going to ultimately fail, if there's no real collaboration with your client. If they're regularly throwing new business rules, or new business requirements over a transome through which you have limited or no visibility, then you are in a no-win situation.
I'm looking into Catel. I started following along in the Getting Started for WPF Developers. I create the initial project using the template and run it. All well and good.
Then I take a detailed look at the generated source files. I see references to DataWindow, StyleHelper, and ViewModelBase. And I run in the debugger and watch the Catel debug output, stepping so that I can see when things happen.
And it is all magical.
The view manager somehow runs and registers the MainWindow. And the ViewModelFactory is invoked to create MainWindowViewModel, and the MainWindow DataContext gets set.
How does this all happen? I am missing the documentation that puts together for me the sequence of events when an application starts. I am reluctant to take it on faith, and reluctant to dive into the giant code base without an inkling of where to start. I have read the CodeProject articles and the intro part of the documentation.
Is this driven off of the behaviors some way? How are they invoked? I just can't find the thread that starts me on my way.
Aside: I look at Catel because I found myself implementing a ton of plumbing for a significant MVVM application, and decided that someone else had already solved this problem.
Thanks for any leads. (And thanks, Geert. This is a significant work.)
-reilly.
If I understand correctly, you are looking for advanced information of the inner workings. I think this part of the documentation might be of interest for you.
It might not provide all information you are looking for, but it should provide some.
About some basic questions:
1) The startup windows is defined in App.xaml (that's standard WPF)
2) Since it derives from DataWindow, it uses WindowLogic => LogicBase. The LogicBase uses the IViewModelLocator to find the right view model based on naming conventions (all documented)
3) Then the IViewModelFactory will instantiate the vm (using dependency injection) and return it to the logic which will set it as datacontext.
Note that as the advanced documentation tells you, Catel injects an additional layer to make a difference between the outside datacontext and the VM datacontext (of a window or user control content).
ps. I really recommend starting to use the latest prereleases via NuGet. Catel 4.0 (will be released very soon) is nearly feature complete and will prevent you from a lot of breaking changes that you have to go through (and it is of course much better :-))
I am using SS 2.1 and just starting out with it. I got everything loaded and it works for the simple tests I've been doing, but a general question: Is there a way to update my build without having to rebuild the entire thing, an example would be if we change the layout of a table. Lets say we have a id, and name, and then later on add id, name and disabled. Is SS smart and able to pick that up or would it require a new build? Thank you very much for your time.
Cheers
I believe you use a command-line app to generate your mapping files, so that command-line app would have to be re-run for that to happen. Second, the mapping code would have to be compiled on the fly after insert...most .net application do not do this.
But the biggest reason you would not want the mappings to be generated on the fly: speed. It takes time to do that, several seconds at least. Then how would you time it? Not every call -- that would be insane. Once a day? when during the day?
So no, SubSonic only generates the mapping files when you ask it to. If you change the database you risk breaking your application.
If you are using the build provider with ASP.NET, building your project will make SubSonic catch the change and update the generated classes.
Otherwise you will need to use SubCommander to generate the classes again.