Is there a BeforeStep equivalent to AfterStep in Cucumber?
If not - has anyone found a solution / workaround?
According to the documentation on Hooks on the Cucumber Wiki on GitHub, the answer is no. There is Before but no BeforeStep. Depending on what you are trying to achieve, Before might do what you need.
So far as Before is executed before each scenario and AfterStep - after each step in scenario, to achieve BeforeStep you can simply place you code in both hooks: Before and AfterStep.
I know it is quite outdated question but:
Before might be used explicitly e.g before scenario but sometimes it is pointles due to fact that it pollute scenarios description.
I use in support/hooks.rb e.g
Before do |scenario|
//something which should be executed before each scenario
end
It might be usefull in case when some action action must be repeted before EVERY scenario in test set.
I am running cucumber within TestNG. I'd like to print the step definition names out as the feature file is processed. This doesn't appear to happen when running under TestNG. If I had a BeforesStep annotation on a method such as beforeStep(StepDefinition sd)
(or something like that), I'd log the step definition name. That would ve very useful.
Is there a different way to do this with Java Cucumber ?
Related
While writing tests for my Laravel package I came across something strange. My empty tests were passing instead of marked as "Risky".
Further investigation led me to the PendingCommand class that has a run() method which makes an assertion on the exit code of the command. This PendingCommand was instantiated by calling $this->astisan('migrate:fresh')->run(). I was able to skip this assertion by calling assertExitCode(null) before running the command. It worked but there is still an assertion happening.
Anybody had this problem before and/or was able to prevent assertions from happening before the actual test is executed?
It would be nice to see which assertions are being made, but I was unable to find this. The only thing I could find was that the Assert class keeps a $count of all the assertions done, not which one.
I will continue my search for a solution and post my findings to this question.
Found out that InteractsWithConsole has a withoutMockingConsoleOutput method that will prevent a mock to be created with assertions.
Final code:
$this->withoutMockingConsoleOutput()
->artisan('migrate:fresh');
I have a protractor test and for some weird reason protractor is telling me that elements which test as being present are undefined when I try to use protractor methods on them like .get(1) or .by.xpath('..').
Please let me know what information is needed to debug this issue.
I made a bad assumption and now realize that the get method does not go through the children but rather all results from given query.
Instead what I needed what element(by.css('css')).element(by.css('css')).
I was wondering if there is any Ruby way of writing the following views spec(without using Capybara/Cucumber/Webrat helpers. Should be just in rspec or rspec-rails):
expect(rendered).to include("<input class='toggle_m' name='result_configuration[information]' type='checkbox' value='1'>")
expect(rendered).to include("<textarea class=details' disabled='disabled' name=result_configuration[info][]'></textarea>")
Thing is, I need to see if the the checkbox is checked(means the value is "1", value is set to "0" when it is unchecked) then textarea should be disabled. Any idea?
Or How would you write this expectation in a more readable way? Suggestions are most welcome.
Thanks.
You could try a regex, but I think your method is good enough.
expect(rendered).should =~ /<input[^>]*name='result_configuration[information]'[^>]*value='1'[^>]*>/
expect(rendered).should =~ /<textarea[^>]*disabled='disabled'[^>]*name=result_configuration[info][][^>]*>
Limitations of this method are that if there are any checked checkboxes and any disabled textareas it will pass, to do anything more I would definitely require capybara or something to actually parse the html (regexes are not parsers)
EDIT: Added the name= part into both regexes as a response to the comment. Only advantage of this method is that it won't break if you change the class of the elements. Unfortunately I don't know any better solution other than external gems.
Writing such tests for the sake of testing and coverage will only make it difficult for someone inheriting the codebase. I have written such tests only to remove them later as changes to UI are more frequent and having such tests slows down developer. if i had to still write them in OO way i would design it on the lines of pageobjects (that's a gem) - wrapper class over dom and few generic helper functions. Also adding a new gem in test group using Gemfile/bundler would not affect production servers.
In TDD how should you continue when you know what your final outcome should be, but not the processing steps you need to get there?
For example your class is being passed an object whose API is completely new to you, You know the class has the information you need but you don't know how to retrieve it yet: How would you go about testing this?
Do you just focus on the desired result ignoring the steps?
Edit 1
package com.wesley_acheson.codeReview.annotations;
import com.sun.mirror.apt.AnnotationProcessor;
import com.sun.mirror.apt.AnnotationProcessorEnvironment;
public class AnnotationPresenceWarner implements AnnotationProcessor {
private final AnnotationProcessorEnvironment environment;
public AnnotationPresenceWarner(AnnotationProcessorEnvironment env) {
environment = env;
}
public void process() {
//This is what I'm testing
}
}
I'm trying to test this incomplete class. I want to test I have the right interactions with AnnotationProcessorEnvironment within the process method. However I'm unsure from the API docs what the right interaction is.
This will produce a file that contains details on the occurrence of each annotation within a source tree.
The actual file writing will probably be delegated to another class however. So this class' responsiblity is to create a representation of the annotation occurrences and pass that to whatever classes need to move it.
In non TDD I'd probably invoke a few methods set a breakpoint and see what they return.
Anyway I'm not looking for a solution to this specific example more sometimes you don't know how to get from A to B and you'd like your code to be test driven.
I'm basing my answer on this video:
http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/
If you have a model/business logic class that's supposed to get some data from a service then I'd go about this way:
Have your model class take the data that it needs in the constructor, rather than the service itself. You could then mock the data and unit test your class.
Create a wrapper for the service, you can then unit test then wrapper.
Perform a fuller test where you actually pass the data from the wrapper to the model class.
General Answer
TDD can be used to solve a number of issues, the first and foremost is to ensure that code changes do not break existing code in regards to their expected behavior. Thus, if you've written a class with TDD, you write some code first, see that it fails, then write the behavior to make it green without causing other tests to become red.
The side-effect of writing the test cases is that now you have Documentation. This means that TDD actually provides answers to two distinct problems with code. When learning a new API, regardless of what it is, you can use TDD to explore it's behavior (granted, in some frameworks this can be very difficult). So, when you are exploring an API, it's ok to write some tests to provide documentation to it's use. You can consider this a prototyping step as well, just that prototyping assumes you throw it away when complete. With the TDD approach, you keep it, so you can always return back to it long after you've learned the API.
Specific Answer to the Example Given
There are a number of approaches which attempt to solve the problem with the AnnotationProcessor. There is an Assertion framework which addresses the issue by loading the java code during the test and asserting the line which the error/warning occurs. And here on Stack overflow
I would create a prototype without the testing to get knowledge of how the api is working. When I got that understanding, I would continue on the TDD cycle on my project
I agree with Bassetassen. First do a spike to understand what is this external API call does and what you need for your method. Once you are comfortable with the API you know how to proceed with TDD.
Never ever Unit Test against an unknown API. Follow the same principle is if you didn't own the code. Isolate all the code you are writing from the unknown or unowned.
Write your unit tests as if the environmental processor was going to be code that you were going to TDD later.
Now you can follow #Tom's advice, except drop step 1. Step 2's unit tests now are just a matter of mapping the outputs of the wrapper class to calls on the API of the unknown. Step two is more along the lines of an integration test.
I firmly believe changing your flow from TDD to Prototyping to TDD is a loss in velocity. Stay with the TDD until you are done, then prototype.
Is there a way in MBUnit to have the same test called multiple times with different parameters in a sequence, as such:
Method1()
Method2(param A)
Method3()
Method2(ParamB)
Method4()
Method2(ParamC)
etc? I've tried using the Order parameter but sadly I was too hopeful in that the Ordering would be considered class-wide rather than test-wide (1,2,3,4,5,6 as opposed to 1,2a,2b,2c,3,4).
Can you explain the reasons for needing this? This sounds like you have dependencies between your test methods, which in general isn't a good way to go about writing test code.
If you need something to be called in a particular sequence then why not simply expose it as a single test method which calls certain submethods in the order of your choosing?