So say I have this class that is just responsible for taking NetworkRequest's and handling their execution on a given server... what do I name it? I can think of lots of verb names but I want to avoid that.
NetworkCommandExecutor
NetworkRequestDistributor
CommandDistributor
RequestDirector
GeneralSchwarzkopf
Related
My team is using aliases to set some important variables which are used within the it('Test',) blocks.
For example, we may be running the following command in a before step:
cy.setupSomeDynamicData()
Then the setupSomeDynamicData() method exists in a another file (ex: commands.js) and the setupSomeDynamicData() method may setup a couple aliases:
cypress/support/commands.js
setupSomeDynamicData() {
cy.createDynamicString(first).as('String1')
cy.createDynamicString(second).as('String2')
cy.createDynamicString(third).as('String3')
}
Now we go back to our spec/test file, and start using these aliases:
cypress/e2e/smallTest.cy.js
it('A small example test', function () {
cy.visit(this.String1)
// do some stuff...
cy.get(this.String2)
// do some stuff...
cy.visit(this.String3)
// do some stuff...
})
The problem is that unless you're the person who wrote the code, it's not obvious where this.String1, this.String2, or this.String3 are coming from nor when they were initialized (from the perspective of smallTest.cy.js) since the code that initializes the aliases is being executed in another file.
In the example, it's quite easy to Ctrl+F the codebase and search for these aliases but you have to really start doing some reverse engineering once you have more complex use cases.
I guess this feels like some sort of readability/maintainability problem because once you setup enough of these and the example I provided starts to get more complex then finding out where these aliases are created can be inconvenient. The this.* syntax makes it feel like you'd find these aliases variables somewhere within the same file in which they're being used but when you don't see any sign of them then it becomes evident that they've just magically been initialized (somewhere/somehow) and then the hunt 🕵🏼♂️ begins.
Some solutions that come to mind (which may be bad ideas) are:
Create JS objects with getters/setters. This way, it'll be a bit easier to trace where the variable you're using was "set"
Not use aliases, and instead, use global variables that can be imported into the spec/test files so it's clear where they are coming from then run a before/after hook to clear these variables so that the reset-per-test functionality remains.
Name the variables in a way where it's obvious that they are aliased and then spread the word/document this method within my team so that anytime they see this.aliasedString2 then they know it's coming from some method that performs these alias assignments.
I'm sure there may be a better way to handle this so just thought I'd post this question.
I am writing test cases for my application and most of my controllers contain common code for CRUDs so I have written common macro and use it inside my controllers. Test cases for all of the controllers would be written automatically. But I am confused about how to make this common code overridable so that I can override whenever I want.
defmodule Qserv.ControllerTest do
defmacro __using__(_options) do
quote location: :keep do
use Qserv.Web.ConnCase, async: true
# this kernel will give me access to current `#model` and `#controller`
use Qserv.KernelTest
describe "#{#controller}.create/2" do
test "All required fields set `required` in model should generate errors that these fields are missing -> One, two, All"
test "Only required fields should create record and match the object"
end
# defoverridable index: 2, I want to override above `describe` completely or/and the included test cases
end
end
end
Any help/idea how to achieve this?
I am generally not a fan of the "let's do things to undo it later". It generally forces developers to keep a stack in their head of how things are added and removed later on.
In this case in particular, you are coupling on the test name. Imagine someone decides to make the "two" in "One, two, All" uppercase. Now all of the future overrides won't apply and you will have duplicate tests.
A better solution to explicit opt in what you need. For example, you can define smaller macros that you use when necessary:
describe_create!
describe_update!
...
describe_delete!
Maybe you could have describe_restful! that invokes all of them. The lesson here is to have small building blocks that you build on top of instead of having a huge chunk that you try to break apart later.
PS: please use better names than the describe_x that I used. :)
The following function iterates through the names of directories in the file system, and if they are not in there already, adds these names as records to a database table. (Please note this question applies to most languages).
def find_new_dirs():
dirs_listed_in_db = get_dirs_in_db()
new_dirs = []
for dir in get_directories_in_our_path():
if dir not in dirs_listed_in_db:
new_dirs.append(dir)
return new_dirs
I want to write a unit test for this function. However, the function has a dependency on an external component - a database. So how should I write this test?
I assume I should 'mock out' the database. Does this mean I should take the function get_dirs_in_db as a parameter, like so?
def find_new_dirs(get_dirs_in_db):
dirs_listed_in_db = get_dirs_in_db()
new_dirs = []
for dir in get_directories_in_our_path():
if dir not in dirs_listed_in_db:
new_dirs.append(dir)
return new_dirs
Or possibly like so?
def find_new_dirs(db):
dirs_listed_in_db = db.get_dirs()
new_dirs = []
for dir in get_directories_in_our_path():
if dir not in dirs_listed_in_db:
new_dirs.append(dir)
return new_dirs
Or should I take a different approach?
Also, should I design my whole project this way from the start? Or should I refactor them to this design when the need arises when writing tests?
What you're describing is called dependency injection and yes, it is a common way of writing testable code. The second method you outlined (where you would pass in the db) is probably more common. Also, you can have the db parameter to your function take a default value so you are able to only specify the mock db in testing cases.
Whether to write your code that way at the outset or modify it later would be a matter of opinion, but if you adhere to the Test-driven development (TDD) methodology then you would write your tests before your code-under-test anyway.
There are other ways to deal with this problem, but you're asking a broad question at that point.
I take it these code fragments are python, which I'm not familiar with, but in any case this looks like the methods are detached from any stateful object and I'm not sure if that's idiomatic python or simply your design.
In an OOD you'd want an object that holds a data access object in its state (similar to your 2nd version) and mock that object for tests. You'd also want to mock the get_directories_our_path part.
As for when this design should be done - as the first step before creating the first code file. You should use dependency injection throughout your code. This will aid in testing as well as decoupling and increased reusability of your classes.
I am trying to find out whether it is possible to start a gen_server with a given state.
I would like to be able to set up a monitor/supervisor that restarts the server with its last valid state when this server crashes.
Any suggestion on how to tackle this problem would be very Welcome.
So far my only idea is to have a special handle_call/3 that changes the server state to the desired state when called, but I would like to avoid modifying the server module and handle this purely from my monitor/supervisor process if possible.
Thank you for your time.
gen_server:init takes argument Args. You can pass whatever state you want and set it as the state of the server. You can pass Args to start_link and it will pass it to init for you.
http://www.erlang.org/doc/man/gen_server.html#Module:init-1
http://www.erlang.org/doc/man/gen_server.html#start_link-3
I think that in your case you might want to store the state in mnesia. That way you don't have to take care of passing last valid state to the gen_server. In case you don't want to start mnesia you can use ETS. Create public ETS in some process that won't die and use it from your gen_server (note that when server that created ets dies, the ets is destroyed)
http://www.erlang.org/doc/man/ets.html
http://www.erlang.org/doc/man/mnesia.html
This question is a little silly, but sometimes it's tough to figure out how to name things correctly. The conversion will parse a config file into XML and vice versa. I want to call the program MyCompany.Config2Xml, but the program also needs to be able to "Xml2Config".
I propose: ConfigParser
In keeping with SqlDataReader, TextReader, XmlReader etc I'd just call it ConfigReader and ConfigWriter.
Or, you could just go the serialization approach and then not have to worry about naming conventions.
CC for short:
ConfigConverter ?
Rather than ConfigParser as proposed by jeffamaphone (+1 for nice username), make it a verb:
parse-config
This makes it read nicely in scripts:
if ! parse-config < config-file > config.xml; then
exit 1
fi
I think it helps a lot to think about the verbs (methods) you intend to use with the class and the role the class plays in the application.
In other words if you envision the operation to be {class}.Get() or {class}.Load() then ConfigParser might be a good choice.
If on the other hand you have a corresponding {Class}.Set() or {class}.Save() operation then something like ConfigManager would be a better choice, particularly if the class will be used to isolate the application from the persistence of its configuration.
If the role of the class is nothing more than part of a standalone application or a step in a longer running process then I would would lean more towards class and method pairs that are more like Convert.ToXml() Convert.ToConfig() or Translate.FromXml() Translate.FromConfig().
General term seems like it would be format convertor, or transformatter (by analogy with transcoder). In terms of the specific names you discuss, I think I'd go with ConfigConvertor.
DaTransmogrifier
UberConvertPlus
Xml2Config2Xml
ConfiguratorX
'XConTrans'
or simply 'Via'
ConfXmlSwitcher :P