4 ms·

I can't say that our tests are slow. We can test our database continuously and independently from our various projects that utilize it. Our integration and smok

I can't say that our tests are slow. We can test our database continuously and independently from our various projects that utilize it. Our integration and smoke tests run continuously as you would expect.

scarface74 10y ago
You can't tell me that you can run a full suite of database dependent tests as you can run a bunch of in memory tests that mock the database queries. How do you handle 5 - 10 devs working concurrently if they are all running tests?
- agentultra 10y ago
  Isolation I guess? I don't know what your experience is and why you think it cannot be anything but slow but... it's not? pgtap lets us unit test our SQL functions, triggers, views, etc. It's integrated with our change management system. It's fast enough and works well.
- jamra 10y ago
  You work from local databases. You keep a migration script that sets up the schema and another migration script that sets up the data. If you create a feature, you must add to each script when merging. You can run unit tests by creating transactions, running the test, and then rolling back at the end. I do get your point, though. It's more convenient to be able to mock your database from your code.
  - scarface74 10y ago
    That's much more complicated than just mocking your context in unit tests.... https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).... Go down to "Testing Query Scenerios". I've wrapped the four "mockset.As" lines into one extension method to make it a lot less verbose.
    - jamra 10y ago
      Yes it is, but it's much less complicated than trying to guess what your generated SQL code will look like.
      - scarface74 10y ago
        No need to guess. Run all of your unit tests without mocking out your DbContext and add the following .... context.Database.Log = log.Info Where Log.info is just a method that accepts a string and take a look at the log file generated from your unit tests.

scarface74 10y ago

You can't tell me that you can run a full suite of database dependent tests as you can run a bunch of in memory tests that mock the database queries. How do you handle 5 - 10 devs working concurrently if they are all running tests?

agentultra 10y ago
Isolation I guess? I don't know what your experience is and why you think it cannot be anything but slow but... it's not? pgtap lets us unit test our SQL functions, triggers, views, etc. It's integrated with our change management system. It's fast enough and works well.
jamra 10y ago
You work from local databases. You keep a migration script that sets up the schema and another migration script that sets up the data. If you create a feature, you must add to each script when merging. You can run unit tests by creating transactions, running the test, and then rolling back at the end. I do get your point, though. It's more convenient to be able to mock your database from your code.
- scarface74 10y ago
  That's much more complicated than just mocking your context in unit tests.... https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).... Go down to "Testing Query Scenerios". I've wrapped the four "mockset.As" lines into one extension method to make it a lot less verbose.
  - jamra 10y ago
    Yes it is, but it's much less complicated than trying to guess what your generated SQL code will look like.
    - scarface74 10y ago
      No need to guess. Run all of your unit tests without mocking out your DbContext and add the following .... context.Database.Log = log.Info Where Log.info is just a method that accepts a string and take a look at the log file generated from your unit tests.