My feature has 4-5 scenarios, all are dependent on fact that certain element is present on page or not. For example username, password field.
How can I skip/ignore entire feature based on this condition.Some like below that I have written for skipping a scenario.
public void skipScenario(String message, Scenario scenario){
if (username==null){
Assume.assumeTrue(false);
}
}
Just like Scenario interface , we have Feature class with several implementations, I don't know which one can has the function to skip it.
From the Cucumber docs: "Each scenario should test one thing and fail for one particular reason. This means there should be no reason to skip steps.
If there does seem to be a reason you’d want to skip steps conditionally, you probably have an anti-pattern. For instance, you might be trying to test multiple things in one scenario or you might not be in control of the state of your test environment or test data.
The best thing to do here is to fix the root cause."
Related
This question already has answers here:
Why not use exceptions as regular flow of control?
(24 answers)
Closed 9 years ago.
Hello I am trying to get a clearer understanding of when to use exceptions and when to not use them. I will give a few case scenarios. Can you let me know which cases I should use exception, and explain why I should or should not? (note: this is not a homework problem).
Scenario 1: I design a computer game where each unit can move to a square on a board. However, some square can be blocked. Should I throw a SquareIsBlockedException to prevent the movement of the unit?
Scenario 2: I insert a record to the database, however it fails because there the unique ID is already present. It throws a DuplicateIDException.
Why should I use exceptions for scenario 2, but not for scenario 1?
1) No. A square being blocked is not an exceptional thing - one can assume it is quite common in your game. Exceptions should be fired when something happens in your program that shouldn't happen.
2) Possibly. Inserting a duplicate record into the database is something that should not happen normally. It might also hint at a bug.
If you fire the exception, you stop the execution flow. This is good - after your system finds out it's inserting a duplicate row, what should it do? It's very likely that you haven't prepared your system to behave correctly in such a scenario. Plus, you can (in your debugger, in your logs, etc.) see what went wrong, which makes fixing your code easier.
It all depends on the use case and in your two examples it could be meaningfull to use exceptions or not.
Exceptions should be used for ... Exceptions. There are some "bad code" examples in the web where Exceptions are used for flow control. Do not do this.
So Ex1 sounds for me for a flow control, use if's or language flow control.
In Ex2 explicit control of duplicates can lead to more code when it is necessary first to hit the db to look up if the ID is already in. Is the ID an automatic id, use Exceptions because the normal case is that autom. ID are all diferent. Is the id a user editable data field (e.g. name), lookup first if the Id already exists.
Erlang obviously has a notion of namespace, we use things like application:start() every day.
I would like to know if there is such a thing as namespace for records. In my application I have defined record user. Everything was fine until I needed to include rabbit.hrl from RabbitMQ which also defines user, which is conflicting with mine.
Online search didn't yield much to resolve this. I have considered renaming my user record and prefixing it with something, say "myapp_user". This will fix this particular issue, until I suspect I hit another conflict say with my record "session".
What are my options here? Is adding a prefix myapp_ to all my records a good practice, or is there a real support for namespaces with records and I am just not finding it?
EDIT: Thank you everyone for your answers. What I've learned is that the records are global. The accepted answer made it very clear. I will go with adding prefixes to all my records, as I have expected.
I would argue that Erlang has no namespaces whatsoever. Modules are global (with the exception of a very unpopular extension to the language), names are global (either to the node or the cluster), pids are global, ports are global, references are global, etc.
Everything is laid flat. The namespacing in Erlang is thus done by convention rather than any other mean. This is why you have <appname>_app, <appname>_sup, etc. as module names. The registered processes also likely follow that pattern, and ETS tables, and so on.
However, you should note that records themselves are not global things: as JUST MY correct OPINION has put it, records are simply a compiler trick over tuples. Because of this, they're local to a module definition. Nobody outside of the module will see a record unless they also include the record definition (either by copying it or with a header file, the later being the best way to do it).
Now I could argue that because you need to include .hrl files and record definitions on a per-module basis, there is no such thing as namespacing records; they're rather scoped in the module, like a variable would be. There is no reason to ever namespace them: just include the right one.
Of course, it could be the case that you include record definitions from two modules, and both records have the same name. If this happens, renaming the records with a prefix might be necessary, but this is a rather rare occurrence in my experience.
Note that it's also generally a bad idea to expose records to other modules. One of the problems of doing so is that all modules depending on yours now get to include its .hrl file. If your module then change the record definition, you will have to recompile every other module that depends on it. A better practice should be to implement functions to interact with the data. Note that get(Key, Struct) isn't always a good idea. If you can pick meaningful names (age, name, children, etc.), your code and API should make more sense to readers.
You'll either need to name all of your records in a way that is unlikely to conflict with other records, or you need to just not use them across modules. In most circumstances I'll treat records as opaque data structures and add functionality to the module that defines the record to access it. This will avoid the issue you've experienced.
I may be slapped down soundly by I GIVE TERRIBLE ADVICE here with his deeper knowledge of Erlang, but I'm pretty sure there is no namespaces for records in Erlang. The record name is just an atom grafted onto the front of the tuple that the compiler builds for you behind the scenes. (Records are pretty much just a hack on tuples, you see.) Once compiled there is no meaningful "namespace" for a record.
For example, let's look at this record.
-record(branch, {element, priority, left, right}).
When you instantiate this record in code...
#branch{element = Element, priority = Priority, left = nil, right = nil}.
...what comes out the other end is a tuple like this:
{branch, Element, Priority, nil, nil}
That's all the record is at this point. There is no actual "record" object and thus namespacing doesn't really make any sense. The name of the record is just an atom tacked onto the front. In Erlang it's perfectly acceptable for me to have that tuple and another that looks like this:
{branch, Twig, Flower}
There's no problem at the run-time level with having both of these.
But...
Of course there is a problem having these in your code as records since the compiler doesn't know which branch I'm referring to when I instantiate. You'd have to, in short, do the manual namespacing you were talking about if you want the records to be exposed in your API.
That last point is the key, however. Why are you exposing records in your API? The code I took my branch record from uses the record as a purely opaque data type. I have a function to build a branch record and that is what will be in my API if I want to expose a branch at all. The function takes the element, priority, etc. values and returns a record (read: a tuple). The user has no need to know about the contents. If I had a module exposing a (biological) tree's structure, it too could return a tuple that happens to have the atom branch as its first element without any kind of conflict.
Personally, to my tastes, exposing records in Erlang APIs is code smell. It may sometimes be necessary, but most of the time it should remain hidden.
There is only one record namespace and unlike functions and macros there can only be one record with a name. However, for record fields there is one namespace per record, which means that there is no problems in having fields with the same name in different records. This is one reason why the record name must always be included in every record access.
I understand that there are #Before and #BeforeClass, which are used to define fixtures for the #Test's. But what should I use if I need different fixtures for each #Test?
Should I define the fixture in the
#Test?
Should I create a test class
for each #Test?
I am asking for the best practices here, since both solutions aren't clean in my opinion. With the first solution, I would test the initialization code. And with the second solution I would break the "one test class for each class" pattern.
Tips:
Forget the one test class per class pattern, it has little merit. Switch to one test class per usage perspective. In one perspective you might have multiple cases: upper boundary, lower boundary, etc. Create different #Tests for those in the same class.
Remember that JUnit will create an instance of the test class for each #Test, so each test will get a distinct fixture (set up by the same #Before methods). If you need a dissimilar fixture you need a different test class, because you are in a different perspective (see 1.)
There is nothing wrong with tweaking the fixture for a particular test, but you should try to keep the test clean so it tells a story. This story should be particularly clear when the test fails, hence the different, well named #Test for each case (see 1.)
I would suggest to create a separate Class based on the different fixtures you need. If you have two different fixtures you need just create two different classes (give them a convenient name). But i would think a second time about that, in particular about the difference in the fixtures and why are the different. May be you are on the way to a kind of integration test instead of unit test?
If you are positive that your fixture is unique to single test then it belongs to #Test method. This is not typical though. It could be that some part of it is unique or you didn't parametrize/extracted it right, but typically you will share a lot of the same data between tests.
Ultimately fixture is part of the test. Placing fixture in #Before was adopted as xUnit pattern because tests always:
prepare test data/mocks
perform operations with SUT
validate/assert state/behavior
destroy test data/mocks
and steps 1 (#Before) and 4 (#After) are reused a lot (at least partially) in related tests. Since xUnit is very serious about test independence it offers fixture methods to guarantee that they always run and test data created/destroyed properly.
I have a GUI tool that manages state sequences. One component is a class that contains a set of states, your typical DFA state machine. For now, I'll call this a StateSet (I have a more specific name in mind for the actual class that makes sense, but this name I think will suffice for the purpose of this question.)
However, I have another class that has a collection (possibly partially unordered) of those state sets, and lists them in a particular order. and I'm trying to come up with a good name for it - not just for internal code, but for customers to refer to it.
The role of this particular second collection is to encapsulate the entire currently used/available collection of StateSets that the user has created. All of the StateSets will be used eventually in the application. A good analogy would be a hand of cards versus the entire table: The 'table' contains all of the currently available hands, while the 'hand' contains a particular collection of cards.
I've got these as starter ideas I could throw out for the class name; I'm not comfortable with either at the moment:
Sequence (maybe...with something else tacked on to the name)
StateSetSet (reasonable for code, but not for customers)
And as ewernli mentions, these are really technical terms, which don't really convey a the idea well. Any other suggestions or ideas?
Sequence - Definitely NOT. It's too generic, and doesn't have any real semantic meaning.
StateSetSet - While more semantically correct, this is confusing. You have a sequence, which implies order, which is different from a set, which does not.
That being said, the best option, IMO, is StateSetSequence, as it implies you have a sequence of StateSet instances.
What is the role/function of you StateSetSet?
StateSetSet or Sequence are technical terms.
Prefer a term that convey the role/function of the class.
That could well be something like History, Timeline, WorldSnapshot,...
EDIT
According to your updated description, StateSet looks to me like StateSpace (the space of all possible states). If the user can then interactively create something, it might be appropriate to speak of a Workspace. If the user creates various state spaces of interest, I would then go for StateSpaceWorkspace. Isn't that a cool name :)
"StateSets" may be sufficient.
Others:
StateSetList
StateSetLister
StateSetListing
StateSetSequencer
I like StateSetArrangement, implying an ordering without implying anything about the underlying storage mechanisms.
I am currently working on a Wikipedia API which means that we have a
database for each language we want to use. The structure of each
database is identical, they only differ in their language. The only
place where this information is stored is in the name of the database.
When starting with one language the straight forward approach to use a
mapping between the tables to needed classes (e.g. Page) looked fine.
We defined an engine and corresponding metadata. When we added a
second
database with its own setup for engine and metadata we ran into the
following error:
ArgumentError:
Class '<class 'wp.orm.types.pages.Page'>' already has a primary mapper defined.
Use non_primary=True to create a non primary Mapper.clear_mappers() will remove
*all* current mappers from all classes.
I found an email saying that there must be at least one primary
mapper, so using this option for all databases doesn't seem feasible.
The next idea is to use sharding. For that we need a way to
distinguish
between the databases from the perspective of an instance, as noted in
the docs:
"You need a function which can return
a single shard id, given an instance
to be saved; this is called
"shard_chooser"
I am stuck here. Is there a way to get the database name given an
Object
it is loaded from? Or a possibility to add a static attribute based on
the engine? The alternative would be to add a language column to every
table which is just ugly.
Am I overseeing other possibilities? Any ideas how to define multiple
mappers for the same class, that map against tables in different
databases?
I asked this question on a mailing list and got this answer by Michael Bayer:
if you'd like distinct classes to
indicate that they "belong" in a
different database, and you have very
clear lines as to how this is
performed, use the "entity_name"
concept described at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/EntityName
. this sounds very much like your use
case.
The next idea is to use sharding. For that we need a way to
distinguish
between the databases from the perspective of an instance, as noted
in
the docs:
"You need a function which can return a single shard id, given an
instance to be saved; this is called "shard_chooser"
horizontal sharding is a method of
storing many homogeneous instances
across multiple databases, with the
implication that you're creating one
big "virtual" database among
partitions - the main concept is
that an individual instance gets
placed in different partitions based
on some ruleset. This is a little
like your use case as well but since
you have a very simple delineation i
think the "entity name" approach is
easier.
So the basic idea is to generate anonymous subclasses for each desired mapping which are distinguished by the Entity_Name. The details can be found in Michaels Link