Refactor how? the system consists of 4 micro-services. In a single sanity scenario, they are all being called (some sort of a smoke test to verify all can communicate with each other when spun up). The database is being written on the last micro-service in line, it's code that being handled by another group. I can ask them to give me an API to mock the db, but that still requires me during setup to access the mock, name the entity and then use that name in the example block. As I don't communicate here with objects like I do with unit-testings (instead I'm using REST API) I see no way how I can achieve that?
Thanks! On Tuesday, August 1, 2017 at 9:25:40 AM UTC+3, Jon Rowe wrote: > > > As it not allowed by RSpec to use a let value inside a before(:all) > block. > > This is for good reason as it’s a bad idea to share test stare, you could > assign a constant but it would be better to refactor your code base not to > depend on an external db for each test like this. > > Jon Rowe > --------------------------- > [email protected] <javascript:> > jonrowe.co.uk > > On Tuesday, 1 August 2017 at 01:39, Jon Gordon wrote: > > Hi again :-) > > So I tried to write couple of RSpec test since we last talked, I'll > mention again I'm writing couple end to end tests to verify all > micro-services are up and running. Please consider the following example. > It's an authentication service, that can create users. Before user is being > created, a schema for the user-type needs to be created on a different > micro-service: > > RSpec.describe 'Authentication' do > subject { AuthenticationService.new } > let(:user_schema) { SchemaService.new } > > context 'When creating a user that does not exists ' do > it 'response with status code 200 (success)' do > schema_name = SecureRandom.uuid.to_s > user_schema.create_schema(schema_name) > payload = JSON.parse(File.read( > 'spec/acceptence/fixtures/feature.json')) > payload['schema_name'] = schema_name > > response = subject.create_user(user: 'my_user', payload: payload) > > expect(response.code).to eq 200 > end > > it 'creates a new user' do > schema_name = SecureRandom.uuid.to_s > user_schema.create_schema(schema_name) > payload = JSON.parse(File.read( > 'spec/acceptence/fixtures/feature.json')) > payload['schema_name'] = schema_name > > subject.create_user(user: 'my_user', payload: payload) > > response = subject.get_user_by_category(category: payload['category' > ]) > remote_entity = JSON.parse(response.body) > > expect(payload.to_json).to eq( > remote_entity['list'][unique_value] > ) > end > end > end > > To keep it dry, I should be moving the whole schema creation into a before > block: > > before > schema_name = SecureRandom.uuid.to > user_schema.create_schema(schema_name) > end > > Before makes sense to me over let here, because it's an action. However, > because the schema is more of a 'pre-condition', I can create it just once, > and avoid multiple schema in my database. Therefore, before(:all) seems > like a better option. > > before(:all) > schema_name = SecureRandom.uuid.to_s > user_schema.create_schema(schema_name) > end > > Now that problem is that when I create user in my examples, I NEED to > schema name, so I need to share context between the before and it block. It > makes sense for me to do it like so: > > let(:schema_name) { SecureRandom.uuid.to_s } > > before(:all) > user_schema.create_schema(schema_name) > end > > Then I can create easily create user in my example like so: > > payload = JSON.parse(File.read('spec/acceptence/fixtures/feature.json')) > payload['schema_name'] = schema_name > > subject.create_user(user: 'my_user', payload: payload) > > Alas, this will not work. As it not allowed by RSpec to use a let value > inside a before(:all) block. So I need to hold a string that can be used in > both the it and before block. It can solved it by defining a Constant or > using Instance variable but both methods feels reek to me. I mentioned I > don't have access to the database (as those are remote machines and they > don't expose the ip for that database) so I can't truncate the db > information and avoid the before block here. > > Thanks! > > On Thursday, July 20, 2017 at 10:57:05 AM UTC+3, Jon Gordon wrote: > > Not in Unit-tests of-course, but It seems like the only option in real > end-to-end testing. The system is quite complex, as it's basically a set of > couple micro-services. Each has it's own unique database (Can be Postgress, > Casanda, Oracle...). In a single End to End test, all databases are > populated with information. Clearing tables between each test can take > time, and is quite complex. The CI process does re-start the containers at > the very start of the test-run (so it's like restarting them to a fresh > state), but not during tests. > > if I'll take the list of music instruments in the Faker gem for example, > It only has around 10 options. So even if I use the unique flag - It will > run out of options after 10 test-cases. I guess use 'msuic instruments' > in one spec file, and 'cat-names' on the other to avoid it, but that means > I need to 'remember' what pool of string I already used in previous tests, > and that's feel even worse for me. > > Thanks. > > > > but I thought that there no better way around it. Because > > On Thursday, July 20, 2017 at 3:29:25 AM UTC+3, Myron Marston wrote: > > In general, if you need absolutely unique strings, `SecureRandom.uuid` is > a good way to get one. UUIDs are universally unique, after all :). > > That said, the fact that you are running out of unique random strings from > faker is concerning. All tests should work off of a "clean slate" in your > database, either by wrapping each test in a rolled-back transaction, or by > truncating your DB tables. Are you "leaking" DB records between tests? > > Myron > > On Wed, Jul 19, 2017 at 12:42 PM, Jon Gordon <[email protected]> wrote: > > Hi Myron, > > I will definitely check the book - looks like it's perfect for RSpec > beginner. Also, thanks for sharing the example online - that's alone can > give me a good starting base :) > > I will ask another question while posting - for unit-testing I'm using > Faker gem to fake common strings. However, in end to end tests, we work > against a database - so even if I'm using the 'unique' method, I'm running > out of unique strings after a while. I'm using 'securerandom' to generate > random number, but wondering if there's a better approach for that. > > Thanks! > > On Wednesday, July 19, 2017 at 6:33:49 PM UTC+3, Myron Marston wrote: > > My upcoming book, Effective Testing with RSpec 3 > <https://www.google.com/url?q=https%3A%2F%2Fpragprog.com%2Fbook%2Frspec3%2Feffective-testing-with-rspec-3&sa=D&sntz=1&usg=AFQjCNHGLaAn9OUSvszwbNhLSkP9Ypy-7A>, > > has an example of building a JSON API using end-to-end acceptance tests, > isolated unit tests, and integration tests. It might fit what you're > looking for better since you mentioned you're looking for examples of > end-to-end testing of REST services. > > The code for the book is all online <https://github.com/rspec-3-book>, as > well. > > All that said, Xavier's screen cast is very good, and I definitely > recommend it, particularly if you do better with videos than printed > materials. > > Myron > > On Wed, Jul 19, 2017 at 4:30 AM, Jon Gordon <[email protected]> wrote: > > Thanks Xavier :) > I will be checking this course! > > Is there perhaps an open-source project with end-to-end spec tests you can > recommend (REST tests are preferred, not Capybara)? something to get a > reference from? > Thank you. > > On Wednesday, July 19, 2017 at 2:24:46 AM UTC+3, Xavier Shay wrote: > > Obligatory plug for > https://www.pluralsight.com/courses/rspec-ruby-application-testing which > touches on some of the themes you're asking about :) > > > On Tue, Jul 18, 2017, at 04:06 PM, Jon Rowe wrote: > > Hi Jon > > A couple of tips, firstly you can stub out your external dependencies for > an end to end test, it just depends on the level of integration you want, > it’s equally fine to do what you propose. For injecting your endpoint (IP, > hostname or otherwise) you have a couple of ways of doing it, the simplest > is to use environment variables e.g. `ENV[‘API_ENDPOINT’]`, or you can > build yourself a config system like you mention. The reason why you don’t > see big projects using external configuration files is it is usually done > at the app level rather than in rspec. > > If you chose to go down the config file route, xml, yml or otherwise, > you’d be better off loading it in a spec_helper or other such support file, > and assigning it somewhere. > > Personally I would go with json fixture files for static json, or a > generator method if it needs to be dynamic. > > Cheers. > Jon > > Jon Rowe > --------------------------- > [email protected] > jonrowe.co.uk > > On Wednesday, 19 July 2017 at 01:52, Jon Gordon wrote: > > > Hi everyone, > > I'm quite new to RSpec, and I have used it mainly for unit-testing. > Lately, a need for a small number of end-to-end tests became relevant. When > writing test-cases, I'm trying to stub all dependencies, but because that's > not an option when doing integration tests, I need some help to understand > what's the proper way to do things. Here's couple of questions: > > 1. The test requires an IP for remote machine (which is not local and > sadly can not be). Obviously, I shouldn't supply the IP inside the spec > file. The simple way is reading an external YML file with the IP (that will > get created automatically during the CI process with the right IP for > example) and populate the IP directly from it. But, I was checking couple > of big project that uses rspec, and I never seen an external configuration > file, so I'm thinking perhaps there is a better way of doing it > > 2. If indeed YML file is the right answer, I'm not sure if reading from > the YML file every spec file (that uses this service) is the right thing to > do? Shouldn't I be using hooks instead for that? > > 3. The test-object is a REST service, and some of the requests require big > json object. I have two options: > a. I can create the json object in the spec file itself (which makes > all information visible to you from the spec file itself, but clutters the > spec) > b. Creating an external default fixture (which is basically a json > file), read from it during the spec, and re-write the values that are > relevant for the specific tests. > > Thank you! > > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/61ac9ade-1045-4211-80d3-441ef01ae7cb%40googlegroups.com > > <https://groups.google.com/d/msgid/rspec/61ac9ade-1045-4211-80d3-441ef01ae7cb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/3FF6FCF2018A482CBDC70C02BAFFB643%40jonrowe.co.uk > > <https://groups.google.com/d/msgid/rspec/3FF6FCF2018A482CBDC70C02BAFFB643%40jonrowe.co.uk?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/28f3f239-1515-437b-b011-82b2dd163502%40googlegroups.com > > <https://groups.google.com/d/msgid/rspec/28f3f239-1515-437b-b011-82b2dd163502%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/c297c4c9-5225-47d9-a6e2-80f461bd1226%40googlegroups.com > > <https://groups.google.com/d/msgid/rspec/c297c4c9-5225-47d9-a6e2-80f461bd1226%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/48d88387-8e71-49a5-b25a-850a79fe4181%40googlegroups.com > > <https://groups.google.com/d/msgid/rspec/48d88387-8e71-49a5-b25a-850a79fe4181%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/3ae74ab4-f4fd-4f17-b87f-4256656b57d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
