I have some comments in feature files that refer to the file itself (like Emacs local variables, or a licence block) or are included to guide future developers. Meta-comments, if you will. Is there any way to keep them from being included in the cucumber run output? In days gone by, in other languages with comment extractors, you could do something like this:
#--
# This a meta-comment for helping developers edit this file.
# it should *not* appear in the output of a run.
#++
# This feature does
# diddly-squat, but the comment should
# appear in the run output
Feature: tell me about it
I suspect that putting meta-comments at the end, after all the Cucumber instructions, would keep them from being extracted/displayed, but that doesn't help for cases in which they need to appear mid-file.
Thanks for any suggestions, answers, and/or pointers to docco about this that I've failed to find so far!
Related
I can't figure out what VS Code's editor.autoIndent setting does. I've tried copy+pasting unindented code with the settings turned on and off and the code is just pasted as it was copied - unindented.
Can someone please explain to me what this setting does and a clear use case?
Thanks!
I wasn't paying attention to the Extensions with indentation rules of the language must be available part of the editor.autoIndent description. I installed the Prettier extension, added it's identifier to "editor.defaultFormatter": "esbenp.prettier-vscode" and editor.autoIndent now works perfectly.
I've also created a video explaining it, which might help.
Many modules in vscode may provide some code formatting, depending on the language to format ...
And there is EditorConfig (https://EditorConfig.org) that should simplify this task, quickly, and once for all environments, as long it is largely supported by other IDE.
Any way, in order to format your code, you'll have to ask for this action, usinf either the F1 key + "format this document", or Ctrl+Maj+I
I'm trying to set up a working ruby project with guard-rspec.
I've mixed together the general method of a tutsplus tutorial with some new syntax as described in the RSpec videos and another post. The project can be found in the stack-overflow-question branch on github.
I'm also trying to practice namespacing as described in Programming Ruby 1.9. So eventually I'd like to have example.rb in my lib/example/ directory.
There's 4 questions I have about my project:
What do I need to put in my Guardfile to watch specific directories in my project for changes? I've several different ways which can be seen in my Guardfile as comments labelled like:
# Watch Specific Directory Attempt X
What is the difference between uncommenting lines 8 and 9 in my Guardfile (bellow Uncomment and set this to only include directories you want to watch) and adding "named group captures" like watch(%r{^lib/(?<path>.+)\.rb$}) { |m| "spec/lib/#{m[:path]}_spec.rb" } as described here
Where do I need to put the --clear option to make it persistent? I know I can run it with my binstub like bin/guard --clear and I've tried putting that in my Guardfile however it didn't work.
Are there any glaring convention, syntax, or clarity mistakes that you see in my project? I feel like I'm duck taping this whole thing together and I'd appreciate some guidance in piecing this thing together in a sensible way.
I'll answer the question in the title and cover the "sub-questions" as I go.
The best way to set up a project (as of now) is to use bundle exec guard --init rspec. This should give reasonable defaults to start work immediately. It's not perfect, but there is a lot of work planed to improve things, so do ask questions on GitHub instead (makes more sense).
Guard has to maintain backward compatibility, so there are some "non-intuitive" things for now and skimming through all the docs first (and wiki) is a good investment to quickly know what's available and where. Asking when confused or in doubt is also a good idea (one issue per question is best).
Guard uses a DSL to simplify setting up listeners. This is a bit non-intuitive and clunky at times, but it does help organize actions into groups, which can help maintain complex workflows. The DSL's command for e.g. clearing the terminal automatically is: (clearing: on). (This answers question 3).
There are all kinds of uses and scenarios, so Guard tries hard to make everyone happy and on every platform too. Guard uses Listen, which watches directories recursively (due to restrictions on OSX mostly). This usually isn't a problem, but for huge directions on OSX this can be very, very slow. That's why Guard lets you select which top directories to watch (like 'lib', 'app', etc.). Watching the whole project directory is very convenient, so that is still the default. More info on this is at the Listen project. So by default all directories (:directories statement) are "physically watched" (take up operating resources), though in Guard you only configure which changes you want to respond to (which is what watch statements do).
The words chosen are a bit misleading at times. E.g. watch in the DSL actually means: "out of all the changes happening, select changes matching ...". The block passed to watch is given the results of the match. That block should return a list of files for the current guard plugin to run. So "watch" probably is more misleading than helpful. "match" would probably be a better choice and it might replace "watch" in the future.
The guard-rspec project runs RSpec on changed files. You can see the exact RSpec commands if you run guard with the debugging option on, e.g. bundle exec guard -d. To simplify setup, Guard::RSpec uses a DSL that should work out-of-the-box if your project follows a given setup. E.g. dsl.watch_spec_files_for(ruby.lib_files) is defined here: so it pretty much already should do what you want if you put all your tested source files in lib. For other folders, you can add your own. E.g. Rails projects typically have sources also in an app directory, so in the default Guard::RSpec template there's an statement: dsl.watch_spec_files_for(rails.app_files) with the pattern defined as: rails.app_files = %r{^app/(.+)\.rb$} If you have a typical case that isn't covered, open an issue in that project. (covers question 2).
Everything looks fine in the example project and suggestions are mostly based on taste or preference. E.g.
Instead of let (:greeter) { Example::RSpecGreeter.new }, I'd use RSpec's implicit subject (but some may argue that it's less explicit and less readable)
if you're testing Example::RSpecGreeter, I'd recommend putting that class in a separate file and including it instead (require 'example/rspec_greeter')
you might add RubCop/Guard::RuboCop for detecting convention issues (covers 4th question)
you might want to check out Guard's own Guardfile used to test itself for a more "real-life" setup without the documentation clutter.
for best results I think it's best to copy a whole existing project and rename the parts you want to change. Usually there are many hours spent still fine-tuning things like alternate RSpec configs for Travis, special gem release tasks, certain workarounds and conveniences, etc.
This is a really basic question. I've been watching Ruby Tapas and really like how Avdi can run his Ruby code and have it recorded directly in the source file. Googling "executing and documenting Ruby code" obviously returns a bunch of stuff about the RDocs for the language itself. Anyone know more specifically what I should look into?
You need to use the t9md / vim-ruby-xmpfilter. Look also the README section.
You need to have rcodetools gem mandatory.
After that go though the issue, I logged.
I wrote tutorials for some Ruby gems I wrote. It is in markdown (Kramdown) text document. To ensure the integrity of the source code in the tutorials as the development of the gems continue I want to extract the source code from the tutorial document and run test to ensure the code is correct and working. Before reinventing the wheel I searched but found nothing on this kind of problem. Is there any software that can help me solve my problem? Ruby software would be cool but I'm not particular about the language. I'm sure I can't be the first person to encounter this problem.
The other option is to only have place holders in the tutorial documents and have all the files externally en then populate the document prior to publishing. This would mean a lot more loose files but would be significantly easier to implement.
Org mode in emacs can do that, but it means you can't write in Markdown.
Are you after something like Ruby DocTest?
You have some code you want to remove associated with an obsolete piece of functionality from a ruby project. How do ensure that you get rid of all of the code?
Some guidelines that usually help in refactoring ruby apply, but there are added challenges because having code that isn't being called by anything won't break any unit tests.
Update: Has anyone written anything that allows you to guess based on your version control history if there are commits where you have since deleted most, but not all, of the code and can point out the remaining code?
Current thoughts:
Identify the outermost part of the stack associated with the obsolete functionality: the binary script calling it, or the unit tests calling it.
Look for methods that are only called by methods associated with the obsolete functionality. I often use git grep for this.
In theory, running mutation testing and looking for code that used to be mutation resistant when the old test suite applied, but is now mutation prone might help. It only helps if your code was well-tested in the first place! (Or you can use code coverage tools such as rcov rather than mutation testing)
Running test suites will ensure you haven't removed anything you shouldn't have!
Using autotest can save you time if you're constantly running tests.
If your code was well-structured, it should be easier to find related methods that need to be removed.
Especially in a dynamically typed language, there is no easy way to do this. If you have unittests, thank the developer that wrote them because it will help you remove the code correctly. But you're basically SOL. Remove the code, if it breaks, put it back, figure out where it broke, attempt to work around it, and repeat.
Look at your code coverage. Any code which isn't covered may be part of the code you have left to remove (if any). (Just be sure you have removed you tests. =])